Hi,

We met the problem below :

A simple Service Flow A is using a document called “docWork” (coded by developer #1)

Service Flow B is using another document called “docWork” too (coded by developer #2)
but service B is calling Service A

How would you do if you want avoid a var conflict, as the 2 developers used the same document NAME ?

Is there any instruction to define that “docWork” in Service A is a private document or a private var ?
(we want the modification of docWork in ServiceA not altering the var in the main ServiceB as a private var)

Does the SCOPE property of a MAP can help us ?

I have the same question about a simple String var which would have the same name in ServiceFlow A and ServiceFlow B.

Regards
PS : here is an example attached
testVar2.zip (15.5 KB)

I had a look at your sample and it is the expected behaviour for the flow service.

Let me know your business usecase, we can think of other options?

Thank you for your reply.
I unfortunaltely know that is expected behavior, but what would you change in my example, for srvSub could work with its own var regardless parents service’s vars ? as if the sub serviceFlow srvSub was using a private var ?

What other options would you use, not using any branch to test if the var exists or not ?

We are considering adding business rules :
namming all our vars with a prefix :

Example :
srvMain : srvMainValue1, srvMainValue2…
srvSub : srvSubValue1, srvSubValue2…
to be sure no var are overwriting themselves between different services

Would it be an acceptable workaround ?

Hi Cedric,

If you specify the scope when you invoke srvSub, srvSub will be restricted to the document you specify and the issue with values being overwritten should not exist.

I suggest defining an input document for srvSub so srvMain will know exactly what srvSub is expecting and then restricting the scope to that document on your invoke.

-Mary

You can try as Mary suggested, see below screen shot mapping (make sure you set the scope on invoke testVar1:srvSub) and if you are expecting your output to be:

2019-03-23 14:02:54 AEDT [ISP.0090.0004C] Before calling srvSub – 1
2019-03-23 14:02:54 AEDT [ISP.0090.0004C] After calling srvSub – 2

https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files/a85af4120eb9c894224d9c60340453b33f473a1a.png 1.5x, https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files/a85af4120eb9c894224d9c60340453b33f473a1a.png 2x" data-dominant-color="F4F5F6">

Capture.PNG898×702 35 KB

Thank you Mary, but my need is a lot more like this : how srvSub can be independant and autonome from srvMain (the parent service).

I need srvSub uses any private documents of its choice, and not depending of the documents declared and used by srvMain.

If I code what you suggest, srvMain and srvSub becomes completly linked (the same doc is used by srvMain and srvSub).

For my need, I expect the srvSub service behavior like a completely autonomous java program behavior.
What ever the documents he uses, must not interfere with the parents services that call it.
and must not interfere with the parents services documents in the pipeline.

If srvMain use a document called “test”, why srvSub can not use another private document called the same ?

Sorry, as I’m french it is a little difficult for me to explain more clarely what I need

What Mary suggests, makes perfectly sense. This way the called service gets only the objects it needs and hence can’t overwrite values inherited from the caller. There is no additional “link” between the caller and the callee because of this.

Programming with scopes is a little bit clumsy IMO. Another approach would be to call services via transformers (as apposed to invoke). This would have the same effect (passing only what is needed to the service).

Sometimes, however, one needs the feature of the INVOKE (that the whole pipeline is passed).

So, there is no general answer. The answer is: it depends

Yes, the Mary’s solution is ideal in another context

For my need it is not convenient, because if a developper A decide to code srvMain, while Developper B has to code srvSub, the potential conflict with 2 var with same name belongs possible.
In this case, the Developper B must always be aware about which doc name he is inherited, and must be carreful of what private document he is going to use (maybe he will need more than 10 private documents).
(today we carrefully care about that, but I was expecting alternatives)

Fml2, you’re right, using a transformer for srvSub works fine, but generally we try to avoid using it.

Thanks to all of you for your help and replies
Regards

Hi Cedric,

In the case above, it is Developer A’s responsibility in srvMain to map the input/output expected by srvSub.

Regarding Developer B, I think that (in general) anytime you change a service that is invoked by other services, you run the risk of impacting those other services and need to review the dependent services, and possibly perform regression testing, to ensure there is no negative impact. It reduces the chance of impact if both input and output are defined for all services when practical.

I don’t know how to make srvSub completely autonomous.

-Mary

Thank you Mary for your additionnal informations