What's the real advantages of ThingWorx Flow ?

[seanccc]

Hi,

I have a question, what's the real advantages of ThingWorx Flow comparing to JavaScript Service ?  

Here are some of the possible advantages and the corresponding objections : 

1. "Flow provides lots of OOTB connector".  --- But if the implementation of connectors are exposed as services in Resources things,  JavaScript service can also call it without using Flow
2. "Flow allows user to map and route between services without coding".  ---  But it's not big deal to implement mapping and route in JavaScript service,  Thing model design and the logic of data transformation are the main work in a project .
3. "Flow ensure the calling sequence of each node,  while JavaScript cannot .  "  ---  This is what I heard , but I don't believe it .   I have written tens of thousands of lines of JavaScript service code and never see any disorder problem between JavaScript service.  And if this point is true , JavaScript service is actually useless. 
4. "In IoT scenarios , you can setup Flow to retrieve data and send notification without writing any code" --- I agree,  but as long as one of the node needs customizing logic , then you must writing code , then Flow loss the advantage.  In any real project , there must be lots of business specific logic , specially in a  Digital Thread project ,  I don't see the real advantages . 
5. "It is a good design by separating the implementation of logic from service orchestration "  ---  Yes ,  But good design is reflected through design documents,  Flow is just a presentation of the design document.  it doesn't help for a good design. 
6. "Flow, as a separated service , can provide the flexibility of scalability"  ---  it could a attractive feature , but currently Flow doesn't has the ability I guess. 

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. 

Could someone tell me , in what kind of scenario ,  Flow is a must , or bring lots of advantages comparing to JavaScript Service . 

Regards,

Sean

[slangley]

Hi @seanccc.

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. 

Regards.

--Sharon