As of December 1, 2020, Focal Point is retired and repurposed as a reference repository. We value the wealth of knowledge that's been shared here over the years. You'll continue to have access to this treasure trove of knowledge, for search purposes only.
Join the TIBCO Community TIBCO Community is a collaborative space for users to share knowledge and support one another in making the best use of TIBCO products and services. There are several TIBCO WebFOCUS resources in the community.
From the Home page, select Predict: WebFOCUS to view articles, questions, and trending articles.
Select Products from the top navigation bar, scroll, and then select the TIBCO WebFOCUS product page to view product overview, articles, and discussions.
Request access to the private WebFOCUS User Group (login required) to network with fellow members.
Former myibi community members should have received an email on 8/3/22 to activate their user accounts to join the community. Check your Spam folder for the email. Please get in touch with us at community@tibco.com for further assistance. Reference the community FAQ to learn more about the community.
I want to create a generic pflow in iway designer (5.5) which follows different paths based on what was the "parent" pflow. Is there an easy way to get the parent pflow name? I would prefer not to pass the name to the subprocess.
thanks
iWay Datamigrator 76, iWay Service Manager 5.5, Windows server 2000,
Hi Tsepe, To paraphrase Darksider's answer to another post:
quote:
Drop a QA agent, iwQAAgent (com.ibi.agents.XDQAAgent) in the subflow, give it a file name and change *When to Always. This provides you with all the SREGs that are in play during the document lifecycle.
If parent flow name is available as an SREG, it will appear in the QA agent's output.
If parent flow name is not available, you will need to set an SREG in the parent pflow, probably to Global and Hdr scope, giving it the name of the parent flow as it's value, and then interrogate the SREG in the sub flow.
Background There is special validation and processing that takes place when you publish a pflow which calls a subflow via the standard Designer Process Object..This results in a snapshot of the subflow code being tightly coupled with the main pflow, and also in any deployment it is included in.
If you instead call the subflow via a Service Object of class XDPFlowAgent, you can force the publish/deployment logic to postpone linkage to the subflow so it becomes dynamic, and it is called by name. This means it will work even when called via a defined SREG (or other iWay Functional Language expression). Inspection of the generated “main flow” constructed this way reveals it does not contains the subflow code.
Procedure 1. In the Designer, use a ServiceObject of type XDPFlowAgent . (this object is used instead of the usual ProcessObject) to call a subflow from the mainflow. All critical processing which may change should be moved to the subflow.
2. Use an SREG to contain the subflow name as the XDPFlowAgent property. Do not use a literal name (or else Designer Test Run will fail; not being able to use Designer Test Run with a literal will be addressed.
3. You may test-run the mainflow against a config (i.e. base) only, not against the registry (this will also be addressed in the near future)
4 .To use or modify the subflow, in the Designer, publish the subflow to Registry
5. Deploy via iSM webconsole : Deployments => Services (if you omit this you get a runtime error)
You can continuously undeploy and re-deploy new versions of the subflow without error, with all callers (i.e the webservice) dynamically inheriting the new subflow version
Focal Point Forums 
