Best practice : input-output vs pipeline to propagate var to sub flow service ?

, ,
#1

Hi,

I’ve a big flow service and because of its size, I’m considering to split it into 2 dedicated services tasks (service1 and service2).

Example :

main => service1 => service2
------ <= service1<=

I have a question about a document list (let’s call it error) used by service1 and service2 (but not used by external other services).

Question:

If service1 has error defined as OUTPUT, what would you do for the service2 :

  • would you add the error documentlist in INPUT/OUTPUT of the service2
    (mapping OUPUT service1.error → INPUT service2.error and mapping OUPUT service2.error → INPUT service1.error))
  • or because the service2 is a sub service, do you just leave service2 read the documentlist in the current pipeline ?
    (in this case, service2 don’t need neither INPUT or OUTPUT)
    ?

Regards

#2

IMO everything a service needs should be declared in its input signature. I.e. every variable in the flow must be either declared as an input parameter or be introduced (computed) in the flow itself. There are situations where a value is passed “under the hood” i.e. without declaring it in the input. But those are very rare cases, and each needs a special justification.

1 Like
#3

Hi Cedric,

I agree with fml2.

Additional thoughts:
mapping from Service1 pipeline to Service2 input is recommended has fml2 has explained, but remapping from Service 2 output to Service 1 pipeline is only neccessary when the document is modified in the Service 2 and you need the modified variant after invocation of Service 2.
When it is not used any longer drop it from the pipeline as earliest as possible.

Regards,
Holger

#4

Thanks a lot for your replies.
It usually what we do, but I wanted to be sure that is the best practice.

Regards

#5

Holger,
but when the document is modified in Service2, why remapping to Service1 is necessary ? (I aways remap but prefer to ask the question)
even it is modified in service2, Service1 keeps the reference of the document, and so, will get the modification, isn’t it ?

#6

Hi Cedric,

this is not easy to answer.

Hopefully the Service Development Help contains a note about that.

When invoking services as Transformer or as “scoped”, it is not guaranteed that the modifications of the invoked service are reflected to the pipeline of the invoking service.

Therefore mapping the outcome of an invoked service explicitly is recommended as a best pratice.

Regards,
Holger

#7

Thank you Holger for your advices.
Regards

#8

If you invoke a service (no matter whether it’s done via ‘invoke’ or a transformer or a scoped call) and pass in a document, the document is passed by reference. Hence all changes made to the document are made to the original. Hence, strictly speaking, you do not need to map it back, because the changes have already been made. It also does not matter whether you drop the document at the end of the called service.

If a service makes changes to a document I prefere to declare the document as an output parameter – just to make it clear that the service does change the document. But, again, technically it’s not necessary.

if you do not want to make the changes to the original you should make a deep clone of it (a shallow one will not suffice).

#9

Very interesting, thanks a lot fml2

#10