Here are some of the possible advantages and the corresponding objections :
So, I really don't see the advantage the Flow , and using Flow cause the exception handling become a complex process, like , a flow has step 1, 2 ,3 , if step2 failed , you have to rollback the effect of step 1 by some compensation operations.
There may be situations where the use of Flow is not the optimal approach, but that really depends on a number of factors. For example, if an organization has a need to integrate only 1-2 data sources, use of Flow in that case may not be warranted. However, organizations over time need to interact with many data sources, and to start building the necessary structure to properly manage those connections can be a non-trivial endeavor. Writing all the complex conditional logic that can be built using flows into code, may not be as easy to follow and maintain. A “good design” should be understood by others and the ease with which it can be changed over time. The visual aspect of Flow is key for others to follow the logic. This can be very useful for non-programmers to avoid the need for coding vs. configuring. In addition, Flow has the built-in functionality to wire into other services to listen to their events and react to them by running flows using Triggers. And this can be extended to include greater functionality via the Connector SDK.
PTC’s commitment to Flow ensures that the product will continue to be enhanced over time--with additional integration features to further support the needs of our customers. The Flow infrastructure provides the necessary framework to build these functionalities.
If you are interested, we can arrange for you to have a discussion with one of our product managers on the merits of Flow and whether Flow would be a good fit for your use cases.