In SAP Cloud Integration (SCI), a consistent and structured naming convention for iFlows is essential for effective maintenance and collaboration. Properly named iFlows help teams quickly grasp their purpose, integration partners, and data flow—reducing confusion and enhancing efficiency.

At Docsys Kalmin Solutions, we’ve developed a practical framework for naming iFlows that simplifies management and ensures clarity. Here’s our guide to help your team adopt these best practices.

---

The Docsys iFlow Naming Template

We use the following naming format for our iFlows:

SCI<iflowid><direction><iflowdesc>

Each component of this structure plays a crucial role. Let’s break it down:

1. SCI<iflowid>

This is the unique identifier of the iFlow, consisting of:

• <class>: A 3-digit code denoting the message class. Examples:
  • 000 for utility messages.
  • 002 for partner integrations.
• <id>: A 5-digit identifier (XXXYY), broken into:
  • XXX: Internal partner ID (e.g., 001 for LumixTech, 002 for VeloCorp).
  • YY: Message sequence number, incremented by steps of 5 or 10 (e.g., 10 for order submission, 20 for acknowledgment).

---

2. <direction>

The direction of the data flow:

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

---

3. <iflowdesc>

A flexible description of the iFlow, especially for partner integrations. It follows this structure:

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

• <partner>: A readable partner name (e.g., LumixTech, VeloCorp).
• <senderAdapter> / <receiverAdapter>: Adapters used in the flow (e.g., HTTP, SFTP, ProcessDirect).
• <msgName>: The message type or process name (e.g., OrderRequest, InvoiceSubmission).

---

Examples of Well-Named iFlows

Here are a couple of examples showcasing our naming convention:

1. SCI00200150_IN_VeloCorp_HTTP_SFTP_OrderRequest

Explanation:

• Handles an inbound (IN) integration for VeloCorp.
• Uses HTTP as the sender adapter and SFTP as the receiver adapter.
• Processes OrderRequest messages.
• Class 002 denotes partner integrations.
• Partner ID 001 identifies VeloCorp.
• Sequence ID 50 is for the OrderRequest message.

---

2. SCI00200151_INT_VeloCorp_HTTP_SFTP_OrderRequest_PostProcess

Explanation:

• An internal (INT) iFlow supporting the OrderRequest process for VeloCorp.
• Handles post-processing logic.
• Uses HTTP and SFTP adapters.
• Sequence ID 51 is specific to this helper iFlow for post-processing.

---

Why Consistent Naming Matters

A structured naming convention offers several benefits:

1. Faster Troubleshooting: Issues can be easily pinpointed by identifying the specific iFlow.
2. Improved Supportability: Clear names reduce the need for extensive documentation.
3. Enhanced Collaboration: Teams can work more efficiently on shared projects.

---

Implementing Standard Naming for New Projects

To ensure consistency:

• Assign a unique class number to each project, purpose, or team.
• Use unique IDs for partners and their associated messages within a class.
• Maintain a shared repository of class numbers, partner IDs, and message IDs. Tools like Excel, Notion, or Azure DevOps work well for this purpose.

---

Conclusion

Adopting a standardized iFlow naming convention in SAP Cloud Integration simplifies management, improves team collaboration, and enhances supportability. At Docsys Kalmin Solutions, we’ve seen how a consistent approach reduces complexity and accelerates integration efforts.

A little consistency goes a long way—start implementing these guidelines today!