Scribd
Upload
25 views1 page

Best Practices in Development

The document outlines best practices for SCPI development, emphasizing the importance of client certificates for authentication, proper versioning and naming conventions for iFlows, and the need to externalize environment-specific parameters. It advises against editing standard content iFlows and creating lengthy integration processes, while encouraging meaningful documentation and debugging practices. The author, Anil Sumanth Yakkali, is an SAP Integration consultant who values knowledge sharing and continuous learning.

Uploaded by

jaydata2018
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
25 views1 page

Best Practices in Development

The document outlines best practices for SCPI development, emphasizing the importance of client certificates for authentication, proper versioning and naming conventions for iFlows, and the need to externalize environment-specific parameters. It advises against editing standard content iFlows and creating lengthy integration processes, while encouraging meaningful documentation and debugging practices. The author, Anil Sumanth Yakkali, is an SAP Integration consultant who values knowledge sharing and continuous learning.

Uploaded by

jaydata2018
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 1

Best Practices in SCPI Development

1. Do not use Datastore or Groovy script to log your payloads, especially for large size or amount of
messages for an interface.
2. Always consider client certificate is the primary mode of authentication while connecting to 3rd
parties in both inbound and outbound scenarios
3. Once Iflow development completed and tested, save as version and update with the correct
description.
4. Follow SCPI naming convention documents provided by the client.
5. Create a POC or Test package for duplicating or creation of POC iFlows.
6. Do not edit standard content iFlows as most of them are only configurable. If the iFlows edited,
new updates cannot be applied to it.
7. Do not create a lengthy iFlows in the Integration process. Use local integration processes to
decentralize the functionalities.
8. Always externalize the parameters which will change based on the environment(Ex: HostName,
URL in Dev, QA or Prod)
9. Group your iFlows in a package falling under the same process. (Ex: OTC, RTR, RTP)
10. Enable Trace for debugging or capture payloads.
11. In case of both the sender and receiver solutions are on-premise, SCPI may not be a suggested
solution considering infrastructure and call per each message cost.
12. Provide meaningful descriptions for iFlows and attach explanatory documents for complex
scenarios in a package.
13. Do not edit your iflows in QA or Prod for configuring parameters. Always use configure the
external parameters and deploy.
14. Set SAP_ApplicationID for the key-based search in the custom iflows to easily track message in
monitoring.

Happy Learning

Anil Sumanth Yakkali

I am SAP Integration consultant. Iam zealous to learn and explore new technologies. Experienced in SAP
PI, PO, CPI, CPI-DS, API Management and OPEN Connectors. Sharing knowledge is the best way to
connect with people and grow your network. Happy Learning!

You might also like