Technical Articles
Cloud integration communication channel design
Choose to design IFlows to make it easy to maintain and more readable.
With growing complexities of the integration requirements as a developer it becomes imperative to design IFlow’s:
- Readable: Which provides USERS clear understanding of steps on high level just by looking into the IFlow.
- Easy to maintain: While configuring on different environments it should be easy to update channel/parameter details.
There are many of such design consideration which we understand as we develop more and more simple/complex interfaces.
With help of this blogpost I am trying to highlight one such example where choosing the right design helps to achieve above mentioned consideration.
| IFlow Design | Configure Parameters | |
| Style1 |  |
 |
| Style2 |  |
 |
If you notice Style1 it might look tidier, with only one receiver but the downside is when we try to configure, it’s difficult to understand which channel we are updating. Even to update we have to select the drop down on Adapter Type and if we have same type of adapter its not possible to differentiate between different channels. If there was an option which reflects channel names it would help but currently there is no label/tag which reflects channel name.
Whereas with Style 2 we can understand the difference based on the Receiver itself and not based on the adapter type. So for the developers or support team who is going to maintain the interface could find it easier to maintain.
Hope this helps! Keep Integrating !!
thanks and regards,
Praveen T
IMHO, I think Style1 is still more accurate in terms for IFlow design. The issue here is not so much about the IFlow design, but on the UI for configuring the parameters.
So I would think the fix would be to get your colleagues in the product development team to have the channel name visible in the selection drop down, or raise a improvement request in the influence project.
Hi Eng Swee Yeoh
Yes I completely agree it needs a change(probably an additonal parameters-- could be channel name should help), but with current avaialble options it becomes difficult to maintain using Style1.
thanks and regards,
Praveen T
Thanks for sharing Praveen, One side benefit of Style2 is having distinct receiver names now populates for easier monitoring and MPL analysis later. Enabling for operational best practices. Cheers!