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: InboundOUT: OutboundINT: 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!
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 TemplateWe 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: InboundOUT: OutboundINT: 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 iFlowsHere are two examples of well-named iflows:SCI00200150_IN_VeloCorp_HTTP_SFTP_OrderRequestExplanation: 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_PostProcessExplanation: 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 MatterHaving 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 ProjectsEach 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. ConclusionFollowing 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! Read More Technology Blogs by Members articles
#SAP
#SAPTechnologyblog