Technical Blog

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

created by Midjourney

Vlado Balko

9. 8. 2024

Integration

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 our company, 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.