Hi All

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

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.

Ade - not at Summit

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