This post touches on some lessons learned and what I consider best practices when developing ICS integration flows.
All Integration Style/Patterns
Map Actions and Complex Transformations
If you’re using SQL with a Database adapter, always pass a binding variable. If you can’t use an Assign action, set the value in the Map instead of the SQL Query. Anytime you touch the SQL Query, the Map has to be re-created and that is just time consuming.
Orchestration Flows
Switch Action
Switch actions will limit a variable’s scope. That can be a good thing, or a bad thing. Make sure you know the scope you desire. The current release does not yet allow you to re-organize actions after they have been placed on the designer canvas, so you will need to re-create them manually.
Assign Action
Create global Assigns outside a Switch activity and then update them wherever needed.
Typically, the most time-consuming part of creating an integration flow is the mapping/transformation needed to convert data from your trigger payload to whatever invoke action you intend. In many cases, you find yourself performing the same exact mapping of a particular piece of data over and over again. With an Assign action, you can perform this map/transformation once and re-use it as often as you’d like.
Connection Agent
When using the connection agent, remember that the connection configuration information you specify in ICS will be local to the connection agent location, not the ICS instance. That is, you can specify “localhost” and that would point to the host that the connection agent is running. All connection urls or ip addresses should be relative to what your connection agent has access to inside your firewall.