Is there a way to use pub.flow:invokeService without knowing the precise passed Service?

[Jan_Bronstering]

Hello everybody!

Let’s assume we pass a data processing Service to invokeService via the ifcname and svcname parameters. I’ll call this service foo. It seems to me that we have to know the signature of foo. So we have to pass foo’s input parameters to the invokeService’s pipeline parameter. Moreover any results from foo have to be known for further use.

What we know is that foo consumes a document and returns another document - both of unknown structure. This makes the basic (and unstructured) document type an abstract type.

Foo could - for example - take a document with two numbers and return one with one number (the sum of the two).

Foo could also take a document with one String and return a document with the reversed String.

All that interests me is that the signature of foo is document → document. But foo itself is not prepared for this approach in way, may it be that the parameters follow a certain naming schematas.

Thank you very much for your help

Jan

[fml2]

Hello,

could you please more clearly describe what exactly you’d like to know?

The signature of foo does not matter. The only relevant thing is what is actually passed as the input. The signature is only a help in the flow editor. Of course one should always strive to pass in values according to the signature and, in the service impl, access and use only declared values. Otherwise programming would become a nightmare. But from the runtime perspective, the signature does not matter.

[Akshith_Arremreddy1 (Akshith Arremreddy)]

Yes, you can invoke the service without knowing the structure of the input but how would you process the inputs inside the processing service?

You can try writing a Java service that will take a generic doc as input create key\value pairs out of it and then process them but that will work flawlessly only if there is one level of doc and all the fields under it are going to be a string.

If we know the use case maybe we can find a better way to do this!

Inputs:
String serviceNameToInvoke
Document inDoc (it should be an empty doc)

IDataCursor pipelineCursor = pipeline.getCursor();
		String	serviceNameToInvoke = IDataUtil.getString( pipelineCursor, "serviceNameToInvoke" );

		IData 	output = IDataFactory.create();
		IData	inDoc = IDataUtil.getIData( pipelineCursor, "inDoc" );
		if ( inDoc != null){
			IDataCursor inputCursor=inDoc.getCursor();
			IDataUtil.put( inputCursor, "ifcname", serviceNameToInvoke.split(":")[0] );
			IDataUtil.put( inputCursor, "svcname", serviceNameToInvoke.split(":")[1] );
			try{
				output = Service.doInvoke( "pub.flow", "invokeService", inDoc );
			}catch( Exception e){
				IDataUtil.put( pipelineCursor, "errorMessage", e.toString());
			}
		}
		else{
			IDataUtil.put( pipelineCursor, "errorMessage", "No Inputs passed!");	
		}
		IDataUtil.put( pipelineCursor, "resultDoc", output );
		pipelineCursor.destroy();

[Jan_Bronstering]

Hello,

Sorry for my late answer and thank you for your responds.

The idea behind was to invoke a batch procedure in a generic way, so that the workload could be spread to several threads.
In terms of Java streams I wanted to achieve a parallel()-like behavior.

I think I have yet another example for my problem with the ‘types’. I want to test a simple “subList” Service. This is a Java Service that takes a DocumentList as input and returns a DocumentList as output. In- and output Documents are of the same structure since the result is nothing more than a cutout of the original.

A service to test can pass specific test data to the subList-Service. But the Service Out provides a ‘plain’ DocumentList, that I’m not able to expand. This would be necessary to compare the result with an expected list. (picture)

So far I tried to implement in flow only. But Java services seems to be a better approach. Thanks again to Akshith Arremreddy - I will have a closer look at your example.

Best regards and Happy holidays

jan

[Holger_von_Thomsen]

Hi Jan,

you will to have to have a local document type describing your output and map the output of the service to the local copy of the output.
After that you can validate against the local copy.

Additionally, from a security point of view such a generic service might violate the restrictions of your company as you cannot control what is passed in and what this causes to your system.

Regards,
Holger