I have the following case:
IDataCursor pipelineCursor = pipeline.getCursor();
String messageType = IDataUtil.getString(pipelineCursor, “MessageType”);
String header = IDataUtil.getString(pipelineCursor, “SourceHeaderType”);
String packageName = IDataUtil.getString(pipelineCursor, “PackageName”);
String rootElement = IDataUtil.getString(pipelineCursor, “rootElement”);


IData result = Service.doInvoke(packageName,header+"_"+messageType,pipeline);

How can I set the result back to the existing pipeline?

I do not exactly understand your problem, is it about getting the result of the called procedure into the IDate result or placing the contents of result in to the output of the calling Java service?
If the latter just use the “generate code for implementation” from Developer to get an example on how to place data into the outgoing pipeline. The contents of result can be access with the standard api. I would not place result directly because it is the output pipeline of the called service.
You should also consider avoiding calles from Java services back to IS services. Sometimes it is needed, but most of the time it can be done in a wrapping flow service.

It is about placing the results of the calling service back to the pipeline. The IData result is itself a pipeline. Therefor I would like to merge the result back to the original one.

Get the single values you want to join out of the pipeline of the subflow and place them as new values in the output of the current service. This way you are sure to have only specified return values in the output.
I wouldn’t try to just merge the two pipelines, I don’t like the merge of pipelines between calling flow services and called flows anyway.

Yes but that means that I for sure know what value/pairs are in the pipeline. I would like to use it as generic service which will return all the given values back to the pipeline.

IDataUtil.merge(IData src, IData dst)

“I don’t like the merge of pipelines between calling flow services and called flows anyway.”

I’m not sure why this would be an objection–invoking any service “normally” will have the same risk of pipeline “litter.” If one is concerned about that then the caller to the Java service can specify a scope when calling or call it via a transformer.