Apex-kutsut lähtevät Salesforcesta, eivät VPN:stäsi
Kannettavan VPN antaa selaimellesi polun, ei Apexille tai Marketing Cloudille. Sovita todellinen kutsuja julkiseen yhdyskäytävään tai hyväksyttyyn yksityiseen yhteyteen.
Yksityinen API vastaa selaimessasi heti, kun kannettava liittyy VPN:ään, joten integraation pitäisi toimia. Se ei toimi, koska kutsun tekevä koodi ajetaan aivan toisaalla. Apex ajetaan Salesforcen sovelluspalvelimilla ja Marketing Cloudin palvelinpuolen toiminto kyseisen tuotteen ajonaikaisessa ympäristössä. Kumpikaan ei peri kannettavasi tunnelia. Tee tämä lyhyenä menettelynä: tunnista kutsuja, valitse sisäänkäynti, johon kutsuja pääsee, kytke polku päästä päähän ja varmista sitten ajonaikaisesta ympäristöstä itsestään.
Kirjoita kutsujakortti ennen mitään verkkomuutosta
Täytä viisi kenttää äläkä suostu arvaamaan yhtäkään niistä. Suoritustuote ja konteksti ratkaisevat kaiken myöhemmän, joten aloita sieltä, älä palvelimen palomuurista.
| Field | What it must answer |
|---|---|
| Runtime | Which product and execution context issues the request? |
| Endpoint | Which hostname must that runtime resolve, and to what? |
| Path | Which supported public entry or private connection carries it? |
| Identity | Which credential and which operation is the API asked to authorize? |
| Failure | How do responses return, and what happens when the path is down? |
Selainvälilehti ja Apex-kutsu ovat kaksi eri asiakasta, ja toimiva selain todistaa vain, että työpöydältäsi on olemassa polku. Jos ajonaikaisen ympäristön kenttä sanoo Apex, olennainen kysymys on, mistä osoitteista Salesforce lähtee, ei se, mitä osoitteita kannettavassasi on. Siksi tunneli, joka saa API:n latautumaan selaimessa, voi jättää integraation epäonnistumaan samalla aikakatkaisulla kuin ennenkin. Kutsujakortti on olemassa, jotta tämä virhe pysäytetään ennen kuin kukaan muokkaa palomuuria.
Valitse sisäänkäynti, jota kutsuja voi todella käyttää
Molemmat mallit ovat hyväksyttäviä, ja ne ratkaisevat eri ongelmia. Ensimmäinen on tarkoituksellinen julkinen sisäänkäynti: HTTPS API-yhdyskäytävä tai integraatiopalvelu, joka todentaa kutsujan, soveltaa kapeita käyttöoikeuksia ja pitää suojatun yhteyden yksityiseen backendin. Se ei ole sama asia kuin jokaisen backend-palvelun paljastaminen tai hallintaportin välittäminen internetiin.
Toinen on hyväksytty yksityinen yhteys. Salesforcen Private Connectin lähtevän liikenteen dokumentaatio kuvaa tuettujen kutsujen reitityksen Outbound Network Connectionin kautta, joka on sidottu nimettyyn käyttäjätunnukseen, määritellyn AWS PrivateLink -järjestelyn yli. Ominaisuudella on versio-, lisenssi- ja tuoterajoituksia, joten varmista, että organisaatio täyttää ehdot ennen kuin suunnittelet sen varaan.
Kumpikaan malli ei ole Salesforceen asennettu OpenVPN-asiakas, ja vanha väite, että jokaisen integraation on yllettävä julkiseen backendiin, on liian laaja siellä, missä tuettu yksityinen yhteys sopii. Valitse se, mitä ajonaikainen ympäristö tukee, ja viimeistele sitten polku todelliseen API:in: AWS-päätepiste ei tunne paikallista resurssiasi eikä peri kannettavasi reittiä. DNS:n, backend-reitityksen, käyttöoikeuskäytännön ja vastausliikenteen on kaikkien noudatettava valitsemaasi arkkitehtuuria. Puolivalmis yksityinen polku epäonnistuu tavalla, joka näyttää täsmälleen todennusongelmalta.
Kytke yksityinen polku päästä päähän
Työskentele API:sta ulospäin ja pysähdy ensimmäiseen aukkoon. Varmista, että backend vastaa paikallisesti, sitten että yksityinen päätepiste tavoittaa sen, ja sitten että nimetty käyttäjätunnus ja sen lähtevä yhteys kohdistuvat siihen päätepisteeseen.
curl -sS -m 5 -o /dev/null -w '%{http_code}\n' http://10.40.8.20:8080/health
dig +short api.partner.example
sf apex run --file scripts/apex/callout-check.apex --target-org integrationEnsimmäinen komento todistaa, että backend on kunnossa yksityisverkon sisältä, toinen näyttää, mihin nimi ratkeaa, ja kolmas suorittaa kutsun todellisesta Salesforcen ajonaikaisesta ympäristöstä. 200 ensimmäisestä ja epäonnistuminen kolmannesta eristävät aukon polkuun tai käyttäjätunnukseen, ei palveluun.
Pidä identiteetin laajuus tarkkana kytkennän aikana. Nimetty käyttäjätunnus ei korjaa yksin saavuttamatonta päätepistettä, koska tunnus ja yksityinen yhteys ovat toisiinsa liittyviä asetuksia, joilla on eri tehtävät. IP-sallittulista kaventaa verkon hyväksyntää eikä ole API-tunnus, joten säilytä tavallinen TLS-varmennus sekä palvelun oma todennus- ja kierrätysprosessi. Jos testi onnistuu vasta, kun poistat varmenteen tarkistuksen käytöstä, olet löytänyt isäntänimiongelman etkä polkuongelmaa, ja varmenteen on silti vastattava.
Varmista ajonaikaisesta ympäristöstä ja kirjaa sitten peruutus
Hyväksy vaaraton sallittu pyyntö integraation ajonaikaisesta ympäristöstä, ei omalta koneeltasi. Kirjaa vastaanottavan palvelun havaittu lähde, todennettu päämies, tulos ja yksi tarkoituksella hylätty pyyntö, jonka on epäonnistuttava.
curl -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://api.partner.example/v1/ping
curl -sS -o /dev/null -w '%{http_code}\n' -H 'Authorization: Bearer invalid' https://api.partner.example/v1/pingAja samat kaksi koetta backendin omasta verkosta, jotta havaittua lähdettä voidaan verrata siihen, mitä ajonaikainen ympäristö tuotti. 200 ja sen perässä 401 tai 403 on haluttu muoto; kaksi 200:aa tarkoittaa, ettei hylkäyspolkua oikeasti valvota.
Kirjoita peruutus ennen kuin tarvitset sitä: mitä sallittulistan merkintää, nimettyä käyttäjätunnusta tai lähtevää yhteyttä muutit, kuka sen omistaa ja miten edellinen arvo palautetaan. Sulje sitten kehä nimeämällä pilvikutsuja ja palvelun täydellinen polku tikettiin, jotta kukaan ei avaa samaa asiaa uudelleen VPN-ongelmana.