[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6EQRTRV77GPHWZX4R9XVGSJ":3,"skill-same:01M6EQRTRV77GPHWZX4R9XVGSJ":64},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":37,"linkOnly":38,"markdownContent":39,"markdownBody":40,"frontMatter":41,"refName":42,"commitSha":43,"skillDirectory":44,"forksCount":45,"repositoryHtmlUrl":46,"repositoryHomepageUrl":47,"ownerHtmlUrl":48,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":49,"install":50,"resources":63},"01M6EQRTRV77GPHWZX4R9XVGSJ","integration-suite",null,"Use when designing, building, troubleshooting, or reviewing SAP Integration Suite artifacts — Cloud Integration (CPI) iFlows, API Management proxies, Integration Advisor B2B templates, Event Mesh, or any middleware pattern connecting SAP and non-SAP systems.","vigneshbarani24\u002Fsap-superpowers","vigneshbarani24","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F20842962?v=4","01M6EQKRW2KZ2M0H75J985XGDX","Vignesh Barani Sivakumar","01M6EQKS0E6EWFSXP4XWK6Y760",11,"MIT","https:\u002F\u002Fgithub.com\u002Fvigneshbarani24\u002Fsap-superpowers\u002Fblob\u002Fmain\u002Fskills\u002Fmodules\u002Fintegration-suite\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36],"integration suite","integration","advisor","event","middleware","systems","proxies","b2b","pattern","sap","mesh","use","management","troubleshooting","api","templates","cloud","artifacts","2026-11-10 10:12:30",false,"---\nname: integration-suite\ndescription: Use when designing, building, troubleshooting, or reviewing SAP Integration Suite artifacts — Cloud Integration (CPI) iFlows, API Management proxies, Integration Advisor B2B templates, Event Mesh, or any middleware pattern connecting SAP and non-SAP systems.\n---\n\n# SAP Integration Suite\n\nGoverns all integration design and implementation on SAP Integration Suite. Every iFlow, API proxy, and B2B scenario MUST be built for resilience, observability, and maintainability — not just for the happy path.\n\n## Content Routing\n\n| Topic | Section |\n|-------|---------|\n| iFlow design and best practices | Iron Laws + iFlow Patterns |\n| API Management | Key Concepts + Integration Points |\n| Error handling and retry | Rationalization Table + Key Concepts |\n| Monitoring and alerting | Transaction Codes \u002F Tools |\n| S\u002F4HANA connectivity patterns | Integration Points |\n| Security and credentials | Key Concepts |\n\n## Iron Laws\n\n1. **NEVER HARD-CODE ENDPOINTS OR CREDENTIALS IN IFLOWS.** Every URL, username, password, client ID, and secret MUST be stored in the tenant's Security Material store (credential name referenced by alias) or Destination Service. Hard-coded values create security vulnerabilities and make tenant migration impossible without code changes.\n2. **ALWAYS EXTERNALIZE CONFIGURATION PARAMETERS.** Runtime environment (DEV\u002FQAS\u002FPRD) differences — endpoint URLs, receiver system IDs, queue names — MUST be externalized via Externalized Parameters (Configure menu on deployed artifact). Changing a parameter should never require re-editing and redeploying the iFlow.\n3. **ALWAYS IMPLEMENT ERROR HANDLING WITH RETRY AND DEAD LETTER QUEUE.** Every iFlow that is not purely synchronous MUST have an Exception Subprocess with: (a) retry logic using a JMS adapter or scheduled re-trigger, (b) alerting to Operations Monitor or SAP Alert Notification Service, and (c) a dead-letter queue or error inbox for messages that exhaust retries. Silent failure is the worst failure mode.\n4. **NEVER USE GROOVY SCRIPTS WHEN CONTENT MODIFIER OR BUILT-IN STEPS CAN DO THE JOB.** Scripts are black boxes: they bypass flow visualization, inhibit low-code modifications, and create maintenance bus factors. Use Message Mapping, Content Modifier, Filter, Splitter, or built-in functions first. Scripts are permitted only for logic that is genuinely impossible with standard steps.\n5. **ALWAYS DESIGN FOR IDEMPOTENCY IN ASYNC SCENARIOS.** Fire-and-forget and pub\u002Fsub patterns MUST assume at-least-once delivery. Receivers must handle duplicate message IDs gracefully. Use the Data Store Write step or Message ID correlation to detect and discard duplicates at the receiver side.\n\n## Rationalization Table\n\n| Agent Will Try To... | Why It Seems Reasonable | Why It Fails | Counter |\n|---|---|---|---|\n| Hard-code the S\u002F4HANA URL in the HTTPS receiver adapter | \"This endpoint doesn't change often\" | URL changes at S\u002F4HANA upgrade, system copy, or migration; breaks without touching source | Store in externalized parameter + Security Material; takes 5 minutes and survives every system change |\n| Use a Groovy script to transform a simple field mapping | \"Scripts are flexible and I know Groovy\" | Script is invisible to business analysts, breaks content modifier display, requires developer every time a field changes | Use Message Mapping or Content Modifier; use Groovy only when XSLT and built-ins genuinely cannot handle the requirement |\n| Skip Exception Subprocess because \"this interface is low risk\" | \"Errors here aren't critical to business\" | Low-risk interfaces become invisible failure points; ops teams can't distinguish \"no messages\" from \"failed messages\" | Every iFlow needs at minimum: exception handling + alert. Low-risk = simpler handling, not no handling. |\n| Reuse a single iFlow for multiple source systems | \"It reduces the number of artifacts to manage\" | Multi-branch iFlows become impossible to read, impossible to monitor individually, and impossible to deploy independently | One iFlow per source-target-message-type combination. Reuse via subprocess references or mapping artifacts, not branching. |\n| Use IDoc adapter for new S\u002F4HANA integrations | \"IDocs are proven and stable\" | New S\u002F4HANA integrations should prefer OData APIs (REST) or Business Events (AMQP via Event Mesh) — IDocs are legacy protocol with no JSON support and weak error semantics | Use OData V4 or SOAP (BAPI\u002FRFC wrapper) for synchronous; Event Mesh for async. IDoc only when target system mandates it. |\n| Store the SFTP private key as a flow variable | \"It's simpler than the keystore\" | Flow variables are plaintext in MPL logs; keys in flow variables are exposed in trace mode and persist in error messages | Use the tenant Keystore for all private keys; reference by alias in the adapter configuration |\n| Deploy directly to production without tracing | \"It worked in QAS\" | Production data volumes and timing expose race conditions invisible in QAS; trace mode must be used to verify production behavior on first few messages | Enable trace mode for 30 minutes post-deployment in production; disable after successful verification |\n\n## Red Flags\n\nWatch for these in your own reasoning — each signals a design or security failure:\n\n- \"I'll put the password directly in the adapter...\" → Immediate Iron Law 1 violation. Check Security Material store; create a credential alias first.\n- \"Let me write a quick script to handle this...\" → Pause. Can a Content Modifier, Filter, or standard mapping step achieve the same result? Only script if the answer is definitely no.\n- \"This interface doesn't need error handling, it's just a notification...\" → Every deployed iFlow needs an Exception Subprocess. \"Just a notification\" that fails silently becomes an incident when business expects action on it.\n- \"We can figure out idempotency later...\" → Idempotency is an architectural decision that cannot be retrofitted without receiver-side changes. Design it in from the start for all async flows.\n- \"Let me just copy the QAS iFlow and change the URL...\" → URL changes belong in externalized parameters, not iFlow copies. Copies create version drift. Use the Configure menu post-deployment.\n- \"The MPL shows green, so we're done...\" → Message Processing Log (MPL) green means the iFlow completed without exception — it does not mean the business process succeeded. Verify the receiver acknowledged the data correctly.\n\n\u003CHARD-GATE>\nBefore designing any iFlow: confirm (1) the integration pattern (sync\u002Fasync\u002Fpub-sub), (2) the security model (credential store aliases for all endpoints), (3) the error handling strategy (retry count, dead letter behavior), and (4) externalized parameters for all environment-specific values. Do not write a single adapter configuration until these four items are decided.\n\u003C\u002FHARD-GATE>\n\n## Key Concepts\n\n### Cloud Integration (CPI)\n- **iFlow (Integration Flow):** The unit of deployment. Contains sender\u002Freceiver adapters, routing, mapping, and processing steps. Deployed as a Maven artifact to the Integration Runtime worker nodes.\n- **Adapters:** HTTPS, SOAP, OData, SFTP, AMQP, JMS, RFC, IDoc, AS2, SuccessFactors, Ariba, and 60+ others. Each has sender and receiver variants.\n- **Message Processing Log (MPL):** Per-message audit trail. Contains header, properties, attachments, and (in trace mode) full payload at each step.\n- **Externalized Parameters:** Runtime-configurable properties set via the Configure tile without redeployment. Environment-specific values belong here, not in iFlow property panels.\n- **Security Material:** Tenant-level store for user credentials (BasicAuthentication), OAuth2 client credentials, PGP keys, and known hosts. Accessed by alias in adapter config — never value.\n- **Keystore:** Tenant-level X.509 certificate store. Used for HTTPS mutual TLS, SFTP key authentication, and message-level signing\u002Fencryption (WS-Security, AS2).\n- **Content Modifier:** Sets message body, headers, and exchange properties. Preferred over scripts for simple value assignment, static payloads, or header manipulation.\n- **Message Mapping:** Graphical XSLT-based mapping editor. Supports functions, constants, value mapping tables. Preferable to Groovy for structured field-level transformations.\n- **Data Store:** Persistent key-value store within Integration Suite tenant. Used for correlation IDs, duplicate detection, and store-and-forward patterns.\n\n### API Management\n- **API Proxy:** Facade over a backend API. Adds policies (security, throttling, transformation, caching) without touching the backend.\n- **Policies:** Pre-built logic units applied at request\u002Fresponse: VerifyAPIKey, OAuthV2, Quota, SpikeArrest, AssignMessage, ServiceCallout, JSONToXML, RaiseFault.\n- **Rate Limiting:** SpikeArrest (burst control, per second\u002Fminute) + Quota (volume control, per day\u002Fmonth). Both are needed — SpikeArrest alone cannot enforce contractual limits.\n- **API Business Hub Enterprise:** Developer portal for API discovery, documentation, and self-service subscription.\n\n### Integration Patterns\n- **Synchronous Request-Reply:** Caller waits for response. Use HTTPS sender → processing → HTTPS\u002FOData receiver. Timeout must be configured at both iFlow and load balancer level.\n- **Async Fire-and-Forget:** Caller sends and continues. Use JMS or AMQP queue as intermediary; separate iFlow polls and delivers. Decouples sender availability from receiver availability.\n- **Pub\u002FSub via Event Mesh:** Publisher raises a CloudEvent to a topic; N subscribers consume independently. Use for domain events (BusinessPartnerChanged, SalesOrderCreated) originating from S\u002F4HANA.\n- **Store-and-Forward:** Messages persisted in Data Store or JMS queue; retried on schedule until receiver is available. Essential for batch receivers with maintenance windows.\n\n### S\u002F4HANA Connectivity — When to Use What\n| Mechanism | Use When |\n|-----------|----------|\n| OData V4 API | Real-time read\u002Fwrite; prefer for new integrations; JSON native |\n| OData V2 API | Existing integrations; still valid but V4 preferred for new |\n| SOAP \u002F BAPI-RFC Wrapper | Complex transactional logic; existing BAPI in S\u002F4HANA |\n| IDoc | Legacy EDI or partner systems that mandate IDoc |\n| Business Events (Event Mesh) | Domain event propagation; async; decoupled; no polling |\n\n## Monitoring Tools\n\n| Tool \u002F Path | Purpose |\n|-------------|---------|\n| Operations Monitor → Message Processing | MPL — per-message status, payload (trace), error details |\n| Operations Monitor → Manage Integration Content | Deployed artifacts, runtime status, start\u002Fstop |\n| Operations Monitor → Manage Locks | Stuck messages in Data Store \u002F sequence locks |\n| Alert Notification Service | Push alerts on iFlow errors to email, Slack, PagerDuty |\n| API Management → Analytics | API call volumes, latency, error rates, top consumers |\n| Trace Mode | Detailed step-by-step payload capture — enable only in non-prod or briefly in prod |\n\n## Integration Points\n\n- **S\u002F4HANA:** Connects via Cloud Connector (on-prem) or direct HTTPS (cloud). Exposes OData V4 APIs, SOAP RFC\u002FBAPI wrappers, IDocs, and Business Events via Event Mesh.\n- **SuccessFactors:** Native SF adapter (OData-based). Used for employee replication, position management, payroll integration.\n- **Ariba \u002F Fieldglass:** Dedicated adapters for procurement and contingent workforce. Handles cXML and AS2 for EDI partners.\n- **Third-Party Systems:** SFTP for legacy file transfer; AS2 for EDI\u002FB2B; REST\u002FHTTPS for modern APIs. Integration Advisor provides B2B message templates (EDIFACT, ANSI X12, IDoc).\n- **BTP Services:** Integration Suite runs on BTP. Connects to XSUAA for OAuth, Destination Service for endpoint management, SAP Event Mesh for pub\u002Fsub, Alert Notification Service for ops.\n\n## Verification\n\nThis skill is complete ONLY when ALL of the following are true:\n\n- [ ] All endpoints stored as Security Material aliases or Destination Service references — no hard-coded values\n- [ ] All environment-specific values defined as Externalized Parameters — confirmed via Configure tile\n- [ ] Exception Subprocess implemented: retry logic configured, alert or logging step present\n- [ ] Idempotency confirmed for all async\u002Fpub-sub iFlows: duplicate detection mechanism in place\n- [ ] Groovy scripts justified in design document — all standard-step alternatives explicitly ruled out\n- [ ] Test messages executed in MPL: green status confirmed AND receiver system verified to have processed correctly\n- [ ] Trace mode enabled during initial production deployment, disabled after first successful batch\n\n**Evidence required:** MPL screenshot showing successful message processing; receiver system record confirming data arrived correctly; no credentials visible in iFlow property panels.\n\n## Next Skill\n\nAfter Integration Suite design or build: `verification-before-completion`\nFor ABAP-side API development in S\u002F4HANA: `abap-cloud`\nFor BTP platform setup and connectivity: `btp`\n\n## Related Skills\n\n- `abap-cloud` — Developing OData APIs and Business Events in S\u002F4HANA\n- `btp` — BTP environment, Destination Service, Event Mesh setup\n- `security-grc` — OAuth, XSUAA, and API security governance\n- `troubleshooting` — Diagnosing iFlow failures from MPL and system logs\n","# SAP Integration Suite\n\nGoverns all integration design and implementation on SAP Integration Suite. Every iFlow, API proxy, and B2B scenario MUST be built for resilience, observability, and maintainability — not just for the happy path.\n\n## Content Routing\n\n| Topic | Section |\n|-------|---------|\n| iFlow design and best practices | Iron Laws + iFlow Patterns |\n| API Management | Key Concepts + Integration Points |\n| Error handling and retry | Rationalization Table + Key Concepts |\n| Monitoring and alerting | Transaction Codes \u002F Tools |\n| S\u002F4HANA connectivity patterns | Integration Points |\n| Security and credentials | Key Concepts |\n\n## Iron Laws\n\n1. **NEVER HARD-CODE ENDPOINTS OR CREDENTIALS IN IFLOWS.** Every URL, username, password, client ID, and secret MUST be stored in the tenant's Security Material store (credential name referenced by alias) or Destination Service. Hard-coded values create security vulnerabilities and make tenant migration impossible without code changes.\n2. **ALWAYS EXTERNALIZE CONFIGURATION PARAMETERS.** Runtime environment (DEV\u002FQAS\u002FPRD) differences — endpoint URLs, receiver system IDs, queue names — MUST be externalized via Externalized Parameters (Configure menu on deployed artifact). Changing a parameter should never require re-editing and redeploying the iFlow.\n3. **ALWAYS IMPLEMENT ERROR HANDLING WITH RETRY AND DEAD LETTER QUEUE.** Every iFlow that is not purely synchronous MUST have an Exception Subprocess with: (a) retry logic using a JMS adapter or scheduled re-trigger, (b) alerting to Operations Monitor or SAP Alert Notification Service, and (c) a dead-letter queue or error inbox for messages that exhaust retries. Silent failure is the worst failure mode.\n4. **NEVER USE GROOVY SCRIPTS WHEN CONTENT MODIFIER OR BUILT-IN STEPS CAN DO THE JOB.** Scripts are black boxes: they bypass flow visualization, inhibit low-code modifications, and create maintenance bus factors. Use Message Mapping, Content Modifier, Filter, Splitter, or built-in functions first. Scripts are permitted only for logic that is genuinely impossible with standard steps.\n5. **ALWAYS DESIGN FOR IDEMPOTENCY IN ASYNC SCENARIOS.** Fire-and-forget and pub\u002Fsub patterns MUST assume at-least-once delivery. Receivers must handle duplicate message IDs gracefully. Use the Data Store Write step or Message ID correlation to detect and discard duplicates at the receiver side.\n\n## Rationalization Table\n\n| Agent Will Try To... | Why It Seems Reasonable | Why It Fails | Counter |\n|---|---|---|---|\n| Hard-code the S\u002F4HANA URL in the HTTPS receiver adapter | \"This endpoint doesn't change often\" | URL changes at S\u002F4HANA upgrade, system copy, or migration; breaks without touching source | Store in externalized parameter + Security Material; takes 5 minutes and survives every system change |\n| Use a Groovy script to transform a simple field mapping | \"Scripts are flexible and I know Groovy\" | Script is invisible to business analysts, breaks content modifier display, requires developer every time a field changes | Use Message Mapping or Content Modifier; use Groovy only when XSLT and built-ins genuinely cannot handle the requirement |\n| Skip Exception Subprocess because \"this interface is low risk\" | \"Errors here aren't critical to business\" | Low-risk interfaces become invisible failure points; ops teams can't distinguish \"no messages\" from \"failed messages\" | Every iFlow needs at minimum: exception handling + alert. Low-risk = simpler handling, not no handling. |\n| Reuse a single iFlow for multiple source systems | \"It reduces the number of artifacts to manage\" | Multi-branch iFlows become impossible to read, impossible to monitor individually, and impossible to deploy independently | One iFlow per source-target-message-type combination. Reuse via subprocess references or mapping artifacts, not branching. |\n| Use IDoc adapter for new S\u002F4HANA integrations | \"IDocs are proven and stable\" | New S\u002F4HANA integrations should prefer OData APIs (REST) or Business Events (AMQP via Event Mesh) — IDocs are legacy protocol with no JSON support and weak error semantics | Use OData V4 or SOAP (BAPI\u002FRFC wrapper) for synchronous; Event Mesh for async. IDoc only when target system mandates it. |\n| Store the SFTP private key as a flow variable | \"It's simpler than the keystore\" | Flow variables are plaintext in MPL logs; keys in flow variables are exposed in trace mode and persist in error messages | Use the tenant Keystore for all private keys; reference by alias in the adapter configuration |\n| Deploy directly to production without tracing | \"It worked in QAS\" | Production data volumes and timing expose race conditions invisible in QAS; trace mode must be used to verify production behavior on first few messages | Enable trace mode for 30 minutes post-deployment in production; disable after successful verification |\n\n## Red Flags\n\nWatch for these in your own reasoning — each signals a design or security failure:\n\n- \"I'll put the password directly in the adapter...\" → Immediate Iron Law 1 violation. Check Security Material store; create a credential alias first.\n- \"Let me write a quick script to handle this...\" → Pause. Can a Content Modifier, Filter, or standard mapping step achieve the same result? Only script if the answer is definitely no.\n- \"This interface doesn't need error handling, it's just a notification...\" → Every deployed iFlow needs an Exception Subprocess. \"Just a notification\" that fails silently becomes an incident when business expects action on it.\n- \"We can figure out idempotency later...\" → Idempotency is an architectural decision that cannot be retrofitted without receiver-side changes. Design it in from the start for all async flows.\n- \"Let me just copy the QAS iFlow and change the URL...\" → URL changes belong in externalized parameters, not iFlow copies. Copies create version drift. Use the Configure menu post-deployment.\n- \"The MPL shows green, so we're done...\" → Message Processing Log (MPL) green means the iFlow completed without exception — it does not mean the business process succeeded. Verify the receiver acknowledged the data correctly.\n\n\u003CHARD-GATE>\nBefore designing any iFlow: confirm (1) the integration pattern (sync\u002Fasync\u002Fpub-sub), (2) the security model (credential store aliases for all endpoints), (3) the error handling strategy (retry count, dead letter behavior), and (4) externalized parameters for all environment-specific values. Do not write a single adapter configuration until these four items are decided.\n\u003C\u002FHARD-GATE>\n\n## Key Concepts\n\n### Cloud Integration (CPI)\n- **iFlow (Integration Flow):** The unit of deployment. Contains sender\u002Freceiver adapters, routing, mapping, and processing steps. Deployed as a Maven artifact to the Integration Runtime worker nodes.\n- **Adapters:** HTTPS, SOAP, OData, SFTP, AMQP, JMS, RFC, IDoc, AS2, SuccessFactors, Ariba, and 60+ others. Each has sender and receiver variants.\n- **Message Processing Log (MPL):** Per-message audit trail. Contains header, properties, attachments, and (in trace mode) full payload at each step.\n- **Externalized Parameters:** Runtime-configurable properties set via the Configure tile without redeployment. Environment-specific values belong here, not in iFlow property panels.\n- **Security Material:** Tenant-level store for user credentials (BasicAuthentication), OAuth2 client credentials, PGP keys, and known hosts. Accessed by alias in adapter config — never value.\n- **Keystore:** Tenant-level X.509 certificate store. Used for HTTPS mutual TLS, SFTP key authentication, and message-level signing\u002Fencryption (WS-Security, AS2).\n- **Content Modifier:** Sets message body, headers, and exchange properties. Preferred over scripts for simple value assignment, static payloads, or header manipulation.\n- **Message Mapping:** Graphical XSLT-based mapping editor. Supports functions, constants, value mapping tables. Preferable to Groovy for structured field-level transformations.\n- **Data Store:** Persistent key-value store within Integration Suite tenant. Used for correlation IDs, duplicate detection, and store-and-forward patterns.\n\n### API Management\n- **API Proxy:** Facade over a backend API. Adds policies (security, throttling, transformation, caching) without touching the backend.\n- **Policies:** Pre-built logic units applied at request\u002Fresponse: VerifyAPIKey, OAuthV2, Quota, SpikeArrest, AssignMessage, ServiceCallout, JSONToXML, RaiseFault.\n- **Rate Limiting:** SpikeArrest (burst control, per second\u002Fminute) + Quota (volume control, per day\u002Fmonth). Both are needed — SpikeArrest alone cannot enforce contractual limits.\n- **API Business Hub Enterprise:** Developer portal for API discovery, documentation, and self-service subscription.\n\n### Integration Patterns\n- **Synchronous Request-Reply:** Caller waits for response. Use HTTPS sender → processing → HTTPS\u002FOData receiver. Timeout must be configured at both iFlow and load balancer level.\n- **Async Fire-and-Forget:** Caller sends and continues. Use JMS or AMQP queue as intermediary; separate iFlow polls and delivers. Decouples sender availability from receiver availability.\n- **Pub\u002FSub via Event Mesh:** Publisher raises a CloudEvent to a topic; N subscribers consume independently. Use for domain events (BusinessPartnerChanged, SalesOrderCreated) originating from S\u002F4HANA.\n- **Store-and-Forward:** Messages persisted in Data Store or JMS queue; retried on schedule until receiver is available. Essential for batch receivers with maintenance windows.\n\n### S\u002F4HANA Connectivity — When to Use What\n| Mechanism | Use When |\n|-----------|----------|\n| OData V4 API | Real-time read\u002Fwrite; prefer for new integrations; JSON native |\n| OData V2 API | Existing integrations; still valid but V4 preferred for new |\n| SOAP \u002F BAPI-RFC Wrapper | Complex transactional logic; existing BAPI in S\u002F4HANA |\n| IDoc | Legacy EDI or partner systems that mandate IDoc |\n| Business Events (Event Mesh) | Domain event propagation; async; decoupled; no polling |\n\n## Monitoring Tools\n\n| Tool \u002F Path | Purpose |\n|-------------|---------|\n| Operations Monitor → Message Processing | MPL — per-message status, payload (trace), error details |\n| Operations Monitor → Manage Integration Content | Deployed artifacts, runtime status, start\u002Fstop |\n| Operations Monitor → Manage Locks | Stuck messages in Data Store \u002F sequence locks |\n| Alert Notification Service | Push alerts on iFlow errors to email, Slack, PagerDuty |\n| API Management → Analytics | API call volumes, latency, error rates, top consumers |\n| Trace Mode | Detailed step-by-step payload capture — enable only in non-prod or briefly in prod |\n\n## Integration Points\n\n- **S\u002F4HANA:** Connects via Cloud Connector (on-prem) or direct HTTPS (cloud). Exposes OData V4 APIs, SOAP RFC\u002FBAPI wrappers, IDocs, and Business Events via Event Mesh.\n- **SuccessFactors:** Native SF adapter (OData-based). Used for employee replication, position management, payroll integration.\n- **Ariba \u002F Fieldglass:** Dedicated adapters for procurement and contingent workforce. Handles cXML and AS2 for EDI partners.\n- **Third-Party Systems:** SFTP for legacy file transfer; AS2 for EDI\u002FB2B; REST\u002FHTTPS for modern APIs. Integration Advisor provides B2B message templates (EDIFACT, ANSI X12, IDoc).\n- **BTP Services:** Integration Suite runs on BTP. Connects to XSUAA for OAuth, Destination Service for endpoint management, SAP Event Mesh for pub\u002Fsub, Alert Notification Service for ops.\n\n## Verification\n\nThis skill is complete ONLY when ALL of the following are true:\n\n- [ ] All endpoints stored as Security Material aliases or Destination Service references — no hard-coded values\n- [ ] All environment-specific values defined as Externalized Parameters — confirmed via Configure tile\n- [ ] Exception Subprocess implemented: retry logic configured, alert or logging step present\n- [ ] Idempotency confirmed for all async\u002Fpub-sub iFlows: duplicate detection mechanism in place\n- [ ] Groovy scripts justified in design document — all standard-step alternatives explicitly ruled out\n- [ ] Test messages executed in MPL: green status confirmed AND receiver system verified to have processed correctly\n- [ ] Trace mode enabled during initial production deployment, disabled after first successful batch\n\n**Evidence required:** MPL screenshot showing successful message processing; receiver system record confirming data arrived correctly; no credentials visible in iFlow property panels.\n\n## Next Skill\n\nAfter Integration Suite design or build: `verification-before-completion`\nFor ABAP-side API development in S\u002F4HANA: `abap-cloud`\nFor BTP platform setup and connectivity: `btp`\n\n## Related Skills\n\n- `abap-cloud` — Developing OData APIs and Business Events in S\u002F4HANA\n- `btp` — BTP environment, Destination Service, Event Mesh setup\n- `security-grc` — OAuth, XSUAA, and API security governance\n- `troubleshooting` — Diagnosing iFlow failures from MPL and system logs\n",{"name":5,"description":7},"main","cf5d032baea1657808fa74369439ea7e9c7e0a20","skills\u002Fmodules\u002Fintegration-suite",3,"https:\u002F\u002Fgithub.com\u002Fvigneshbarani24\u002Fsap-superpowers","https:\u002F\u002Fsap-superpowers.vercel.app\u002F","https:\u002F\u002Fgithub.com\u002Fvigneshbarani24","2026-08-23 17:03:43",{"source":8,"skillName":5,"commands":51,"prompt":61,"zipAvailable":62},[52,55,58],{"tool":53,"command":54},"npx","npx skills add vigneshbarani24\u002Fsap-superpowers --skill integration-suite",{"tool":56,"command":57},"bunx","bunx skills add vigneshbarani24\u002Fsap-superpowers --skill integration-suite",{"tool":59,"command":60},"pnpm","pnpm dlx skills add vigneshbarani24\u002Fsap-superpowers --skill integration-suite","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fvigneshbarani24\u002Fsap-superpowers\u002Fblob\u002Fmain\u002Fskills\u002Fmodules\u002Fintegration-suite\u002FSKILL.md",true,[],[65,91,98,107,116,125],{"skillNo":66,"name":67,"nameZh":6,"description":68,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":69,"categories":70,"keywords":71,"publishedAt":37},"01M6EQTMCBV605ETS5WWEQX209","s4hana-migration","Use when advising on S\u002F4HANA migration approach, assessing greenfield vs brownfield vs selective data transition options, analyzing custom code impact, reviewing simplification items, or building a migration business case or timeline.","https:\u002F\u002Fgithub.com\u002Fvigneshbarani24\u002Fsap-superpowers\u002Fblob\u002Fmain\u002Fskills\u002Fstrategic\u002Fs4hana-migration\u002FSKILL.md",[],[72,73,74,75,76,77,78,79,80,81,82,83,30,84,85,86,87,88,89,90],"migration","s4hana migration","data","case","impact","discover","simplification","project","brownfield","options","business case","project manager","business","technical","architect","timeline","analyzing","code","prepare",{"skillNo":92,"name":93,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":96,"publishedAt":37},"01M6EQTGJHSYYQDMBJY0APE19X","rise-licensing","https:\u002F\u002Fgithub.com\u002Fvigneshbarani24\u002Fsap-superpowers\u002Fblob\u002Fmain\u002Fskills\u002Fstrategic\u002Frise-licensing\u002FSKILL.md",[],[97],"rise licensing",{"skillNo":99,"name":100,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":103,"publishedAt":37},"01M6EQTCVAJPYQ7A8SA49A1Y72","joule-strategy","https:\u002F\u002Fgithub.com\u002Fvigneshbarani24\u002Fsap-superpowers\u002Fblob\u002Fmain\u002Fskills\u002Fstrategic\u002Fjoule-strategy\u002FSKILL.md",[],[104,105,106],"joule strategy","joule","strategy",{"skillNo":108,"name":109,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":112,"publishedAt":37},"01M6EQTA7RMJ6RNFDTK1E2E9YY","clean-core-strategy","https:\u002F\u002Fgithub.com\u002Fvigneshbarani24\u002Fsap-superpowers\u002Fblob\u002Fmain\u002Fskills\u002Fstrategic\u002Fclean-core-strategy\u002FSKILL.md",[],[113,114,115,106],"clean core strategy","clean","core",{"skillNo":117,"name":118,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":119,"categories":120,"keywords":121,"publishedAt":37},"01M6EQT6QCR8MJ7J62ZP8WZ578","activate-methodology","https:\u002F\u002Fgithub.com\u002Fvigneshbarani24\u002Fsap-superpowers\u002Fblob\u002Fmain\u002Fskills\u002Fstrategic\u002Factivate-methodology\u002FSKILL.md",[],[122,123,124],"methodology","activate","activate methodology",{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":131,"publishedAt":37},"01M6EQT3XFHC6Y2F0EWQ62PHSR","strategic","strategic skills category for SAP Superpowers. Contains 5 sub-skills.","https:\u002F\u002Fgithub.com\u002Fvigneshbarani24\u002Fsap-superpowers\u002Fblob\u002Fmain\u002Fskills\u002Fstrategic\u002FSKILL.md",[],[127,132,28],"superpowers"]