Ways to specify Method Output

[CathyC]

In MVC there seems to be 3 ways to specify that there is a node in the submethod that needs to be brought up to the parent level. I think they work in different ways. Can someone please clarify what each of them are, how they should be used, and how they difference?

1. Set on a service level output to true
2. using method output service
3. specifying output in the callmethod service

[SteveCap]

This is only for when a Call service (CallMethod, CallMethodAdvanced, CallSubMethod, CallSubMethodAdvanced) has Classic = False

The MethodOutput service will allow you to return name value pairs to the call service. It will output as WorkData/CallMethod/Output/Result/Name. Only one MethodOutput service can be used.

The Call service Outputs nodes are used to bring a service from the method up to the WorkData of the caller. It would be added as WorkData/ServiceFromMethod/Output/Result. It would then act just like if it was ran from that process. For this to work the services SelectOutput flag should be true though currently that is a bug and it still will work even if you don't. The fix to require the SelectOutput flag to be true is in queue to be tested.

[CathyC]

I talked more with the internal team on this and have a better understanding of the approaches

The call method (or other service) has a parameter called "Classic". This is a legacy flag to allow them to continue working as they did before. To use the legacy approach, Classic should be set to "True".

When Classic='False':

1. This approach is meant to be used in combination with #3. If a service is flagged as output within the logic canvas, when calling that method, if using approach #3, it will be listed in the recommended values.

   

   

2. From the logic canvas where you put the CallMethod service, you will reference this output like WorkData/CallMethod/Output/Result/Success
   This cannot be used for arrays (not recommended at least). So it is best for returning nodes like "Success" and "Message" which every method should have.
   

   

   

   image.png (13.36 KiB) Viewed 1252 times

   

   image.png (13.36 KiB) Viewed 1252 times

   However, if your method has array data to return, it should not be returned using the MethodOutput service.
   If you really need to accomplish this and you wanted to reference the output of your method like:
   
   WorkData/CallMethod/Output/Result/Inquire/Output/Result
   Or
   WorkData/CallMethod/Output/Result/Items/Item
   
   You could build this out manually using the "Xml/Xsl Mode" option in the MethodOutput service:
   

   

   But this requires a lot of setup on your side to manipulate the xml to be the structure you need instead of using the built in EASYProcess features.
3. specifying the output in the callmethod service brings it a level up so if you look in the logs when it runs it is just as if you had that inquire in your parent logic canvas and didnt have to call a method for it. This must be used in combination with #1 above.
   This is the recommended way to specify output if you have an array (the way for #2 above is for only advanced uses that require it).
   

   

   

   image.png (6.83 KiB) Viewed 1252 times

   

   image.png (6.83 KiB) Viewed 1252 times

[CathyC]

When Classic = 'True':

1. Flagging a service to "Expose Service Output" makes it referencable as a child of the CallMethod when it is ran from the parent logic canvas:
   

   

   So this would be referenced as: WorkData/CallMethod/Output/Result/ServiceWithinMethodFlaggedForOutput/Output/Result/ChildNodeOfService
   
   This downside of this approach was that the references get to be very long. This is why the new way was created, but this will still work if classic mode is turned on.
2. Approach #2 is similar when classic is turned on as to when it is off. The difference is that there are more steps in between which make the path to reference longer.
   

   

   So this would be referenced:
   WorkData/CallMethod/Output/Result/_MethodOutput/Result/ChildNodeOfMethodOutputService
   
   Since approach #1 was the way all method output used to be referenced before the new way, and since approach #2 is very similar by offering the same disadvantage with none of the benefits, it doesnt make much sense to use this.
3. Approach #3 will not work if classic mode is on. These parameters will exist, and you can fill them out, but when the CallMethod runs, it will not produce a new node in the parent logic canvas the way it would work if classic was False.