A Practical Guide to Naming iFlows in SAP Cloud Integration (SCI)

[vbalko-claimate]

In SAP Cloud Integration (SCI), naming iflows clearly and consistently is crucial for maintainability and support. A structured naming convention helps teams quickly understand an iflow’s purpose, its integration partners, and its data flow. At CLAIMATE Tech, we follow a well-defined approach to naming our iflows, and here’s our guide to making it work for you.

Our Naming Template

We use the following format for naming iflows in SCI:

SCI<iflowid>_<direction>_<iflowdesc>

Each part of this structure serves a specific purpose. Let’s break it down:

SCI<iflowid>

The unique identifier of the iflow.

• <class> A 3-digit code representing the message class (e.g., 000 for utility messages or 002 for partner integrations).
• <id> A 5-digit identifier, structured as XXXYY.
• XXX Our internal partner ID for easy identification (e.g., 001 for LumixTech, 002 for VeloCorp).
• YY Sequence number for the message, usually incremented in steps of 10 or 5 (e.g., 10 for order submission, 20 for acknowledgment).

<direction>

The data flow direction.

• IN: Inbound
• OUT: Outbound
• INT: Internal (non-partner-related utility iflow)

<iflowdesc>

A flexible description of the iflow, typically used for partner integrations.

It usually follows the structure:

• <partner>_<senderAdapter>_<receiverAdapter>_<msgName>

where

• <partner> A human-readable name for the partner (e.g., LumixTech, VeloCorp).
• <senderAdapter> and <receiverAdapter> The adapters used (e.g., HTTP, SFTP, ProcessDirect).
• <msgName> The message or process name (e.g., OrderRequest, InvoiceSubmission).

Example iFlows

Here are two examples of well-named iflows:

SCI00200150_IN_VeloCorp_HTTP_SFTP_OrderRequest

Explanation: This iflow handles an inbound (IN) integration for partner VeloCorp, using HTTP as the sender adapter and SFTP as the receiver adapter, with the message type OrderRequest. Message is from class 002 which can be eg. Partner integration and is 001 is lookup id for partner VeloCorp. This message has its id 50 so orderRequests from VeloCorp and its utility iflow starts with digit 5.

SCI00200151_INT_VeloCorp_HTTP_SFTP_OrderRequest_PostProcess

Explanation: This is an internal iflow that serves as a first (51)helper for the OrderRequests (51) integration with VeloCorp, handling PostProcess logic for the OrderRequest message, also using HTTP and SFTP adapters.

Why Naming Conventions Matter

Having a consistent naming convention allows for:

• Easier troubleshooting: Issues can be quickly traced to specific iflows.
• Improved supportability: The team can easily understand each iflow without needing extensive documentation.
• Enhanced collaboration: Clear naming rules allow different teams to work on the same integration projects more efficiently.

Standardizing Naming for New Projects

Each project or purpose or team should have its own class number. That class number must be unique. Also ID for partners must be unique for class and ID of message must be unique per partner.

Maintaining a shared list of these IDs and their purposes in a central knowledge base—like Excel, Notion, or Azure DevOps—would ensure clarity and prevent duplication.

Conclusion

Following these naming guidelines will make your iflows easier to manage, support, and collaborate on within SAP Cloud Integration. Remember: a little consistency goes a long way!

[ShaikAzmathulla]

Hi ,

Thank you for the clear guide on naming iflows in SAP Cloud Integration. I agree that a structured naming convention is crucial for maintainability and support. The breakdown of your naming template and the examples provided are very helpful. Maintaining unique identifiers and a centralized knowledge base will enhance collaboration and prevent duplication. Consistency really does make a difference!

Regards , 

[NareshDasika18]

Thank you for the blog post on the CPI naming conventions used at your organisation.

It would be helpful if you could provide insights on how these naming conventions are applied in a multi-tier environment, specifically when CPI integration flows are connecting to DEV, QAS, and UAT environments.

[vbalko-claimate]

Hi @NareshDasika18,

this naming convention is meant for multi tier environment, where you have separated tenant for dev/test and prod.

For customers, which do have only one tenant (used both as dev/test and prod) we add letter T or P after SCI. So my example 

SCI00200150_IN_VeloCorp_HTTP_SFTP_OrderRequest

will become

SCIT00200150_IN_VeloCorp_HTTP_SFTP_OrderRequest

or 

SCIP00200150_IN_VeloCorp_HTTP_SFTP_OrderRequest

Mind the 4th character T or P. In that case we also maintain two packages for each project one for test and one for prod. Same with endpoints on Sender adapters (like http).

[NareshDasika18]

Got it ! Thanks. 

[Peter_555]

Hello,

how do you deal with Iflows that have several endpoints or are subprocesses that are called via direct process? Your example only display quite simple scenarios.

[vbalko-claimate]

Hi @Peter_555,

Multiple endpoints are usually not a problem, because all those endpoints should be part of the same partner - and iflow is for partner and process. 

Of course rule has always exceptions, so if you have specific integration flow, which belongs to more partners (for some reason) you can reflect that also in the name. eg. add multi or just prefix "m". I`ll leave it to your imagination. Just be consistent.

And for process direct - its also easy (imho), process direct is just another type of adapter, so you will use it in the name - or maybe its shorter form like PD or ProcDir

SCI00200150_IN_VeloCorp_HTTP_ProcDir_OrderRequest

Remark: Process Direct iflows are most likely used inside of chain of iflows - so they do not communicate with partner, but they are more like "internal" ones. So you cannot say, that they are IN or OUT. They are INT (like internal).

So it will become

SCI00200150_INT_VeloCorp_HTTP_ProcDir_OrderRequest