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 சிக்கலாகத் திறக்காதிருக்க.