Apex కాల్‌అవుట్‌లు మీ VPN నుండి కాదు, Salesforce నుండి బయలుదేరుతాయి
ల్యాప్‌టాప్ VPN మీ బ్రౌజర్‌కు మార్గాన్ని ఇస్తుంది, Apex లేదా Marketing Cloud కు కాదు. నిజమైన కాలర్‌ను పబ్లిక్ గేట్‌వే లేదా అర్హత గల ప్రైవేట్ కనెక్షన్‌తో సరిపోల్చండి.
ల్యాప్‌టాప్ VPN లో చేరిన క్షణంలోనే ప్రైవేట్ API మీ బ్రౌజర్‌లో స్పందిస్తుంది, కాబట్టి ఇంటిగ్రేషన్ పని చేయాలి. అది పని చేయదు, ఎందుకంటే కాల్ చేసే కోడ్ పూర్తిగా వేరే చోట నడుస్తుంది. Apex Salesforce అప్లికేషన్ సర్వర్లపై, Marketing Cloud సర్వర్-సైడ్ యాక్టివిటీ ఆ ఉత్పత్తి రన్‌టైమ్‌లో నడుస్తాయి. రెండూ మీ ల్యాప్‌టాప్ టన్నెల్‌ను వారసత్వంగా పొందవు. దీన్ని చిన్న విధానంగా చేయండి: కాలర్‌ను గుర్తించండి, ఆ కాలర్ చేరుకోగల ప్రవేశాన్ని ఎంచుకోండి, మార్గాన్ని మొదటి నుండి చివరి వరకు కలపండి, ఆపై రన్‌టైమ్ నుండే ధృవీకరించండి.
ఏదైనా నెట్‌వర్క్ మార్పు ముందు కాలర్ కార్డ్ రాయండి
ఐదు ఫీల్డ్‌లను నింపి, వాటిలో ఏదీ ఊహించడానికి నిరాకరించండి. ఎగ్జిక్యూషన్ ఉత్పత్తి మరియు సందర్భం తరువాతి అన్నీ నిర్ణయిస్తాయి, కాబట్టి సర్వర్ ఫైర్‌వాల్ నుండి కాదు, అక్కడి నుండే ప్రారంభించండి.
| 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? |
బ్రౌజర్ ట్యాబ్ మరియు Apex కాల్ రెండు వేర్వేరు క్లయింట్‌లు, పని చేసే బ్రౌజర్ మీ డెస్క్ నుండి మార్గం ఉందని మాత్రమే నిరూపిస్తుంది. రన్‌టైమ్ ఫీల్డ్ Apex అని చెబితే, సంబంధిత ప్రశ్న Salesforce ఏ చిరునామాల నుండి బయటకు వెళుతుంది అనేది, మీ ల్యాప్‌టాప్‌లో ఏ చిరునామాలు ఉన్నాయి అనేది కాదు. అందుకే API బ్రౌజర్‌లో లోడ్ అయ్యేలా చేసే టన్నెల్ కూడా ఇంటిగ్రేషన్‌ను మునుపటి అదే టైమౌట్‌తో విఫలం చేయవచ్చు. ఎవరైనా ఫైర్‌వాల్ సవరించే ముందు ఆ పొరపాటును ఆపడానికే కాలర్ కార్డ్ ఉంది.
కాలర్ నిజంగా ఉపయోగించగల ప్రవేశాన్ని ఎంచుకోండి
రెండు డిజైన్లు చెల్లుబాటు అయ్యేవి, అవి వేర్వేరు సమస్యలను పరిష్కరిస్తాయి. మొదటిది ఉద్దేశపూర్వక పబ్లిక్ ప్రవేశం: కాలర్‌ను ప్రామాణీకరించే, సన్నని అనుమతులను వర్తింపజేసే, ప్రైవేట్ backend తో రక్షిత కనెక్షన్ ఉంచే HTTPS API గేట్‌వే లేదా ఇంటిగ్రేషన్ సేవ. ఇది ప్రతి backend సేవను బహిర్గతం చేయడం లేదా నిర్వహణ పోర్ట్‌ను ఇంటర్నెట్‌కు పంపడం వంటిది కాదు.
రెండవది అర్హత గల ప్రైవేట్ కనెక్షన్. Salesforce యొక్క అవుట్‌బౌండ్ Private Connect పత్రాలు మద్దతు ఉన్న కాల్‌అవుట్‌లను పేరు పెట్టిన క్రెడెన్షియల్‌కు కట్టిన Outbound Network Connection ద్వారా, దాని నిర్వచించిన AWS PrivateLink ఏర్పాటుపై ఎలా రూట్ చేస్తారో వివరిస్తాయి. ఈ ఫీచర్‌కు ఎడిషన్, లైసెన్స్ మరియు ఉత్పత్తి పరిమితులు ఉన్నాయి, కాబట్టి దాని చుట్టూ డిజైన్ చేసే ముందు సంస్థ అర్హత పొందిందని నిర్ధారించండి.
ఈ డిజైన్లలో ఏదీ Salesforce లోపల ఇన్‌స్టాల్ చేసిన OpenVPN క్లయింట్ కాదు, ప్రతి ఇంటిగ్రేషన్ పబ్లిక్ backend చేరుకోవాలనే పాత వాదన మద్దతు ఉన్న ప్రైవేట్ కనెక్షన్ సరిపోయే చోట చాలా విస్తృతం. రన్‌టైమ్ మద్దతు ఇచ్చేదాన్ని ఎంచుకోండి, ఆపై నిజమైన API వరకు మార్గాన్ని పూర్తి చేయండి: AWS ఎండ్‌పాయింట్ మీ స్థానిక వనరును తెలియదు, మీ ల్యాప్‌టాప్ మార్గాన్ని వారసత్వంగా పొందదు. DNS, backend రూటింగ్, యాక్సెస్ విధానం మరియు ప్రతిస్పందన ట్రాఫిక్ అన్నీ మీరు ఎంచుకున్న నిర్మాణాన్ని అనుసరించాలి. సగం నిర్మించిన ప్రైవేట్ మార్గం ప్రామాణీకరణ సమస్యలా కనిపించే విధంగానే విఫలమవుతుంది.
ప్రైవేట్ మార్గాన్ని మొదటి నుండి చివరి వరకు కలపండి
API నుండి బయటకు పని చేసి మొదటి ఖాళీ వద్ద ఆగండి. backend స్థానికంగా స్పందిస్తుందని, తరువాత ప్రైవేట్ ఎండ్‌పాయింట్ అక్కడికి చేరుతుందని, ఆపై పేరు పెట్టిన క్రెడెన్షియల్ మరియు దాని అవుట్‌బౌండ్ కనెక్షన్ ఆ ఎండ్‌పాయింట్‌ను లక్ష్యంగా చేసుకుంటాయని నిర్ధారించండి.
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 integrationమొదటి ఆదేశం ప్రైవేట్ నెట్‌వర్క్ లోపలి నుండి backend ఆరోగ్యంగా ఉందని నిరూపిస్తుంది, రెండవది పేరు ఏమిటికి రిజాల్వ్ అవుతుందో చూపిస్తుంది, మూడవది నిజమైన Salesforce రన్‌టైమ్ నుండి కాల్‌ను అమలు చేస్తుంది. మొదటి నుండి 200 మరియు మూడవ నుండి వైఫల్యం ఖాళీని సేవకు కాదు, మార్గానికి లేదా క్రెడెన్షియల్‌కు వేరు చేస్తాయి.
కలుపుతున్నప్పుడు గుర్తింపు పరిధిని ఖచ్చితంగా ఉంచండి. పేరు పెట్టిన క్రెడెన్షియల్ ఒంటరిగా చేరుకోలేని ఎండ్‌పాయింట్‌ను సరిచేయదు, ఎందుకంటే క్రెడెన్షియల్ మరియు ప్రైవేట్ కనెక్షన్ వేర్వేరు పనులతో కూడిన సంబంధిత సెట్టింగ్‌లు. IP అనుమతి జాబితా నెట్‌వర్క్ ప్రవేశాన్ని సంకుచితం చేస్తుంది, అది API క్రెడెన్షియల్ కాదు, కాబట్టి సాధారణ TLS ధృవీకరణ మరియు సేవ యొక్క స్వంత ప్రామాణీకరణ మరియు భ్రమణ ప్రక్రియను నిలబెట్టుకోండి. ఒక పరీక్ష ధృవపత్ర తనిఖీని నిలిపివేసిన తర్వాతే విజయవంతమైతే, మీరు మార్గ సమస్యను కాదు, హోస్ట్‌నేమ్ సమస్యను కనుగొన్నారు, ధృవపత్రం ఇప్పటికీ సరిపోలాలి.
రన్‌టైమ్ నుండి ధృవీకరించి, ఆపై రోల్‌బ్యాక్ నమోదు చేయండి
మీ మెషీన్ నుండి కాదు, ఇంటిగ్రేషన్ రన్‌టైమ్ నుండి హానికరం కాని అనుమతించిన అభ్యర్థనను అంగీకరించండి. స్వీకరించే సేవ యొక్క గమనించిన మూలం, ప్రామాణీకృత ప్రిన్సిపాల్, ఫలితం మరియు విఫలం కావలసిన ఉద్దేశపూర్వకంగా తిరస్కరించిన ఒక అభ్యర్థనను నమోదు చేయండి.
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/pingఅదే రెండు పరీక్షలను backend యొక్క స్వంత నెట్‌వర్క్ నుండి అమలు చేయండి, దానితో గమనించిన మూలాన్ని రన్‌టైమ్ ఉత్పత్తి చేసిన దానితో పోల్చవచ్చు. 200 తర్వాత 401 లేదా 403 మీకు కావలసిన ఆకారం; రెండు 200 అంటే తిరస్కరణ మార్గం నిజంగా అమలు కావడం లేదు.
అవసరం రాకముందే రోల్‌బ్యాక్ రాయండి: ఏ అనుమతి జాబితా నమోదు, పేరు పెట్టిన క్రెడెన్షియల్ లేదా అవుట్‌బౌండ్ కనెక్షన్ మీరు మార్చారు, దాని యజమాని ఎవరు, మునుపటి విలువను ఎలా పునరుద్ధరించాలి. తరువాత టికెట్‌లో క్లౌడ్ కాలర్ మరియు సేవ యొక్క పూర్తి మార్గాన్ని పేరు పెట్టి చక్రాన్ని మూసివేయండి, అదే విషయాన్ని ఎవరూ మళ్లీ VPN సమస్యగా తెరవకుండా.