Hi,
Would like some thoughts on this.
If flow service A makes a call to flow service B using wm.b2b.edi.util:invoke will flow service B have access to A’s pipeline ?
Based on my testing I think the answer is no.
If this is true, can someone share some workarounds. I don’t want to add the object I want to access in B to the “Input” parameter for the wm.b2b.edi.util:invoke service, because that means changing the signature for a lot of B type flow services.
Shubhro
Hi,
I made this post on Friday, but didn’t get any response.
Trying once again to see if it fetches any response this time.
The original post is pasted below:
“Would like some thoughts on this.
If flow service A makes a call to flow service B using wm.b2b.edi.util:invoke will flow service B have access to A’s pipeline ?
Based on my testing I think the answer is no.
If this is true, can someone share some workarounds. I don’t want to add the object I want to access in B to the “Input” parameter for the wm.b2b.edi.util:invoke service, because that means changing the signature for a lot of B type flow services”
Shubhro
Shubhro,
I thought that if you specify the input field with the same name as the object being accessed in the called service, you wouldn’t have to change its signature. For example, if I use the invoke service to call savePipelineToFile and specify fileName with a value as the input, it works OK. I’m guessing you’re trying to do something a bit more complicated than this. Can you provide any details? Thanks,
Tim
shubhro wrote:
“If flow service A makes a call to flow service B using wm.b2b.edi.util:invoke will flow service B have access to A’s pipeline? Based on my testing I think the answer is no.”
You are correct. Only the variables supplied in the input parameter are passed to the service. You can write your own equivalent Java service, however, using the appropriate Service.doInvoke to pass the entire pipeline if desired. I think there is code on the forum for this. Also, PSUtilities has a service you could use as a pattern to make your own service.
shubhro wrote:
“I don’t want to add the object I want to access in B to the “Input” parameter for the wm.b2b.edi.util:invoke service, because that means changing the signature for a lot of B type flow services.”
I assume that the parameter isn’t declared as an input on service B. If not, I’d offer that structured programming practices would indicate that you should in fact “fix” the signatrue for all the B type flow services. A service should never (in my opinion) refer to a variable that is not declared as an input or that the service did not create. Referring to undeclared variables is the same as using global variables in C, Java, etc. and carries all the same maintenance implications. There is an old saying that may be applicable here: “No matter how far down the wrong path you’ve travelled, turn around.”
Tim,
Thanks for the response.
You’re right. I don’t need to add anything to the signature of the called service if I pass the required object from the calling service while using “wm.b2b.edi.util:invoke”.
But this might lead to some ambiguity in terms of understanding the code when someone sees something being passed from a calling service but not seeing it in the input tab of the called service.
I tried savePipeline and restorePipeline and it works fine.
But I am worried that it can be memory intensive as this flow service is for processing X12 documents some of which can be quite big.
Shubhro
Thanks Rob.
I think I will settle for declaring this required object in the called service as an Input parameter and have the calling service pass in that object while calling “wm.b2b.edi.util:invoke”.
Shubhro