Hi,

The transition away from SOAP api was important as those OLD API methods were in place only  to serve as a temporary holdover for people migrating from OO 9.x to OO 10.x .  In OO 10.x  the solution is to use REST API which overall are easier to use and can provide better security. Now for direct API triggering of flows see  Execute a flow by UUID - Operations Orchestration  and if execution is required via CLI  see OOSH Run OO Central commands from the command line - Operations Orchestration

Hope this helps,

Vlad

Hi Vlad,
I remember this well and moving to Rest API via the flows UUID.
This was an issue when we moved to OO 2019.07 from OO 9.07 as the flow UUIDs could change between environments like Development and system test and Production.
Hence our preference was to use flow path vs UUID
Since we migrated to OO 2019.07 all those years ago which still used the PAS rest methods I never really looked at if triggering via API or OOSH using flow path was now possible.
So I agree with this upgrade to 24.1 we need to move forward and remove PAS rest methods but am really hoping there is a method using flow path vs UUID

Thanks,
Terry

The uuid change issue should not occur. A flow's uuid does not change after flow creation regardless of the number of edits. The only way a flow's uuid changes is if the flow has been either deleted and a new flow is created with the same name, or in the case of save flow as/copy flow scenario where duplicates of the flow are created. In the described scenario where the same content pack is deployed in both prod and test the same flow will have the same uuid. 

If you look at older versions of API for the flow uuid parameter you could provide either the flow uuid or flow path and the trigger would work. Over time there have been issues noted with flow path where due to spaces or regional characters the identification of the flow would fail and as such the documentation switched to flow uuid only. Testing on your environment using flow path would be the best way to see if it works for you or not based on your specific naming scheme. 

Placing older PAS.war within the tomcat webapps will not work as the SOAP endopint also required OO code to make it work and that code is no longer part of the product.

Thanks Vlad, The flows changing UUID was more how people were using the environments.
For example they would make flows in Dev and UAT with the same flow path and name but slightly different.
This obviously made things a logistical nightmare with people having to develop changes across four environments.

With this upgrade we are standardising across the board so they only develop once and the jar goes across all environments.
But I am still hoping to minimise changes for all the users of OO.
Moving to rest with json not so bad, the flow UUID vs flow path will be the biggest pain point for some people.