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 ಅನ್ನು ಬ್ರೌಸರ್‌ನಲ್ಲಿ ಲೋಡ್ ಮಾಡುವ ಸುರಂಗವು ಸಂಯೋಜನೆಯನ್ನು ಹಿಂದಿನಂತೆಯೇ ಅದೇ ಟೈಮೌಟ್‌ನೊಂದಿಗೆ ವಿಫಲವಾಗಿ ಬಿಡಬಹುದು. ಯಾರಾದರೂ ಫೈರ್‌ವಾಲ್ ಸಂಪಾದಿಸುವ ಮೊದಲು ಆ ತಪ್ಪನ್ನು ನಿಲ್ಲಿಸಲು ಕರೆದವರ ಕಾರ್ಡ್ ಇದೆ.
ಕರೆದವರು ನಿಜವಾಗಿ ಬಳಸಬಹುದಾದ ಪ್ರವೇಶವನ್ನು ಆರಿಸಿ
ಎರಡೂ ವಿನ್ಯಾಸಗಳು ಕಾನೂನುಬದ್ಧವಾಗಿವೆ, ಮತ್ತು ಅವು ಬೇರೆ ಬೇರೆ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುತ್ತವೆ. ಮೊದಲನೆಯದು ಉದ್ದೇಶಪೂರ್ವಕ ಸಾರ್ವಜನಿಕ ಪ್ರವೇಶ: ಕರೆದವರನ್ನು ದೃಢೀಕರಿಸುವ, ಸಂಕುಚಿತ ಅನುಮತಿಗಳನ್ನು ಅನ್ವಯಿಸುವ ಮತ್ತು ಖಾಸಗಿ ಬ್ಯಾಕೆಂಡ್‌ಗೆ ಸಂರಕ್ಷಿತ ಸಂಪರ್ಕವನ್ನು ಇಟ್ಟುಕೊಳ್ಳುವ HTTPS API ಗೇಟ್‌ವೇ ಅಥವಾ ಸಂಯೋಜನಾ ಸೇವೆ. ಇದು ಪ್ರತಿ ಬ್ಯಾಕೆಂಡ್ ಸೇವೆಯನ್ನು ಬಹಿರಂಗಪಡಿಸುವುದು ಅಥವಾ ನಿರ್ವಹಣಾ ಪೋರ್ಟ್ ಅನ್ನು ಇಂಟರ್ನೆಟ್‌ಗೆ ರವಾನಿಸುವುದಕ್ಕೆ ಸಮಾನವಲ್ಲ.
ಎರಡನೆಯದು ಅರ್ಹ ಖಾಸಗಿ ಸಂಪರ್ಕ. Salesforce ನ ಹೊರಹೋಗುವ Private Connect ದಾಖಲೆ ಬೆಂಬಲಿತ ಕರೆಗಳನ್ನು ಹೆಸರಿಸಲಾದ ರುಜುವಾತಿಗೆ ಬದ್ಧವಾದ Outbound Network Connection ಮೂಲಕ, ಅದರ ನಿರ್ದಿಷ್ಟ AWS PrivateLink ವ್ಯವಸ್ಥೆಯ ಮೇಲೆ ಹೇಗೆ ರೂಟ್ ಮಾಡಲಾಗುತ್ತದೆ ಎಂದು ವಿವರಿಸುತ್ತದೆ. ಈ ವೈಶಿಷ್ಟ್ಯಕ್ಕೆ ಆವೃತ್ತಿ, ಪರವಾನಗಿ ಮತ್ತು ಉತ್ಪನ್ನ ನಿರ್ಬಂಧಗಳಿವೆ, ಆದ್ದರಿಂದ ಅದರ ಸುತ್ತ ವಿನ್ಯಾಸ ಮಾಡುವ ಮೊದಲು ಸಂಸ್ಥೆ ಅರ್ಹವಾಗಿದೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿ.
ಎರಡೂ ವಿನ್ಯಾಸಗಳಲ್ಲಿ ಯಾವುದೂ Salesforce ಒಳಗೆ ಸ್ಥಾಪಿಸಲಾದ OpenVPN ಕ್ಲೈಂಟ್ ಅಲ್ಲ, ಮತ್ತು ಪ್ರತಿ ಸಂಯೋಜನೆಯೂ ಸಾರ್ವಜನಿಕ ಬ್ಯಾಕೆಂಡ್ ತಲುಪಬೇಕು ಎಂಬ ಹಳೆಯ ಹೇಳಿಕೆ ಬೆಂಬಲಿತ ಖಾಸಗಿ ಸಂಪರ್ಕ ಹೊಂದುವ ಸ್ಥಳಗಳಲ್ಲಿ ತುಂಬಾ ವಿಶಾಲವಾಗಿದೆ. ರನ್‌ಟೈಮ್ ಬೆಂಬಲಿಸುವದನ್ನು ಆರಿಸಿ, ನಂತರ ನಿಜವಾದ API ಗೆ ಮಾರ್ಗವನ್ನು ಪೂರ್ಣಗೊಳಿಸಿ: AWS ಎಂಡ್‌ಪಾಯಿಂಟ್ ನಿಮ್ಮ ಸ್ಥಳೀಯ ಸಂಪನ್ಮೂಲವನ್ನು ತಿಳಿದಿಲ್ಲ ಮತ್ತು ನಿಮ್ಮ ಲ್ಯಾಪ್ಟಾಪ್‌ನ ರೂಟ್ ಅನ್ನು ಆನುವಂಶಿಕವಾಗಿ ಪಡೆಯುವುದಿಲ್ಲ. DNS, ಬ್ಯಾಕೆಂಡ್ ರೂಟಿಂಗ್, ಪ್ರವೇಶ ನೀತಿ ಮತ್ತು ಪ್ರತ್ಯುತ್ತರ ಸಂಚಾರ ಎಲ್ಲವೂ ನೀವು ಆರಿಸಿದ ವಾಸ್ತುಶಿಲ್ಪವನ್ನು ಅನುಸರಿಸಬೇಕು. ಅರ್ಧ ನಿರ್ಮಿತ ಖಾಸಗಿ ಮಾರ್ಗವು ನಿಖರವಾಗಿ ದೃಢೀಕರಣ ಸಮಸ್ಯೆಯಂತೆ ಕಾಣುವ ರೀತಿಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ.
ಖಾಸಗಿ ಮಾರ್ಗವನ್ನು ಆರಂಭದಿಂದ ಕೊನೆಯವರೆಗೆ ಜೋಡಿಸಿ
API ಯಿಂದ ಹೊರಕ್ಕೆ ಕೆಲಸ ಮಾಡಿ ಮತ್ತು ಮೊದಲ ಕೊರತೆಯಲ್ಲಿ ನಿಲ್ಲಿಸಿ. ಬ್ಯಾಕೆಂಡ್ ಸ್ಥಳೀಯವಾಗಿ ಉತ್ತರಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ, ನಂತರ ಖಾಸಗಿ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಅದನ್ನು ತಲುಪುತ್ತದೆ ಎಂದು, ನಂತರ ಹೆಸರಿಸಲಾದ ರುಜುವಾತು ಮತ್ತು ಅದರ ಹೊರಹೋಗುವ ಸಂಪರ್ಕವು ಆ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಅನ್ನು ಗುರಿಯಾಗಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ.
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ಮೊದಲ ಆದೇಶವು ಬ್ಯಾಕೆಂಡ್ ಖಾಸಗಿ ನೆಟ್‌ವರ್ಕ್ ಒಳಗಿನಿಂದ ಆರೋಗ್ಯಕರವಾಗಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಎರಡನೆಯದು ಹೆಸರು ಯಾವುದಕ್ಕೆ ಪರಿಹರಿಸುತ್ತದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ಮೂರನೆಯದು ನಿಜವಾದ 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ಅದೇ ಎರಡು ಪರೀಕ್ಷೆಗಳನ್ನು ಬ್ಯಾಕೆಂಡ್‌ನ ಸ್ವಂತ ನೆಟ್‌ವರ್ಕ್‌ನಿಂದ ಚಲಾಯಿಸಿ, ಇದರಿಂದ ಗಮನಿಸಿದ ಮೂಲವನ್ನು ರನ್‌ಟೈಮ್ ಉತ್ಪಾದಿಸಿದ ಮೂಲದೊಂದಿಗೆ ಹೋಲಿಸಬಹುದು. 200 ನಂತರ 401 ಅಥವಾ 403 ನೀವು ಬಯಸುವ ಆಕಾರ; ಎರಡು 200 ಎಂದರೆ ನಿರಾಕರಣ ಮಾರ್ಗವು ನಿಜವಾಗಿ ಜಾರಿಯಾಗುತ್ತಿಲ್ಲ.
ಅಗತ್ಯವಾಗುವ ಮೊದಲೇ ರೋಲ್‌ಬ್ಯಾಕ್ ಬರೆಯಿರಿ: ಯಾವ ಅನುಮತಿ ಪಟ್ಟಿ ನಮೂದು, ಹೆಸರಿಸಲಾದ ರುಜುವಾತು ಅಥವಾ ಹೊರಹೋಗುವ ಸಂಪರ್ಕವನ್ನು ನೀವು ಬದಲಿಸಿದ್ದೀರಿ, ಅದರ ಮಾಲೀಕರು ಯಾರು ಮತ್ತು ಹಿಂದಿನ ಮೌಲ್ಯವನ್ನು ಹೇಗೆ ಮರುಸ್ಥಾಪಿಸುವುದು. ನಂತರ ಟಿಕೆಟ್‌ನಲ್ಲಿ ಕ್ಲೌಡ್ ಕರೆದವರ ಮತ್ತು ಸೇವೆಯ ಪೂರ್ಣ ಮಾರ್ಗವನ್ನು ಹೆಸರಿಸಿ ಚಕ್ರವನ್ನು ಮುಚ್ಚಿ, ಇದರಿಂದ ಯಾರೂ ಅದೇ ವಿಷಯವನ್ನು ಮತ್ತೆ VPN ಸಮಸ್ಯೆಯಾಗಿ ತೆರೆಯುವುದಿಲ್ಲ.