Hi,
I have two results sets ResultSet1 and ResultSet2 and they both have the same count always.
Is it possible to loop both result sets at the same time and fetch the values for both same time at each iteration?
ResultSet1 - Message
ResultsSet2 - MessageID
The count of both the result sets is always the same.
How do I assign the pipeline variables by looping both at the same time
ResultSet1[0].Message = V_Message
ResultSet2[0].MessageID = V_MessageID
Thanks!

You can loop over one of them. Then use the $iteration or your own index var to reference the other.

@mm4wm – As @reamon said, good Flow requires you to use $iteration

But as a thought experiment, this hack may work:- set ResultSet1 as ‘input array’, and ResultSet2 as ‘output array’ in the LOOP. Even though you’re not mapping into the second set, the Flow statements should let you access arrays elements from both arrays at the same index value.

Even if this does work, this approach may be confusing for maintenance. Consider developers that come after you and only use it with lots of comments

Very cool workaround but I agree on the confusion @Sonam_Chauhan. Using $iteration will be more readable. Another option would be implementing a Java service @mm4wm. Since additional pipelines are not created for each iteration it will be much more faster. If you need to implement a complex logic, just implement a java service.

I may have missed something but there is nothing in the thread indicating that using Java would provide a benefit.

There is also no indication that speed is a concern. Speed is usually addressed via measuring/profiling where the time is spent and improving the specific bottleneck, rather than assuming one approach is faster than another and optimizing prematurely. In most cases the speed differences are minor and immaterial. The “copy of the pipeline” during INVOKE is frequently mentioned as a speed problem but that is something that is trivial to overcome using scope or invoking as a transformer (assuming one has measured and determined this is where the time is spent).

Regarding “complex logic” there have been many threads over the many, many years. Complex is in the eye of the beholder. The recommendation to use Java is typically based upon relatively ill-defined terms of “complex” and “faster”.

This is definitely a YMMV item, but IME it is very rare to resort to a Java service for “complex mapping.” Instead, we have focused utilities such as string manipulation, using collections, etc. The main “driver” is a FLOW service, calling utilities like concat, split, regex-based search/replace, add to map, and so on. We never have a Java service that performs “complex logic” as the “main” service. Of course there are Java services, but the “logic” is in FLOW, not Java.

In general, resist the urge to write something in Java. Of course there are times it is the “right” way but using Java should be the exception, not the common practice.

As always, just my $0.02.

I thought my comment was clear but I guess not.

Complex can be a relative term. We don’t know anything about the iteration requirement, hence using Java service can be viable here, we cannot know that for sure without having more information. Using java service will be definitely faster if any data in the pipeline that is generated in previous iterations, is used in the next iteration, it can be repeat or it can be loop, doesn’t really matter; therefore my comment applies here. It is an option to consider if performance is a concern.

What I meant by complex is if something is not easily implemented using flow services in other terms if it requires complex workarounds/solutions and if java makes it easier, using java service is not a problem, in fact it can be a better solution and sometimes it can be the only solution.

Hope this helps

The comment was clear. Complex is always a relative term. My comments were intended to present an alternate view on “use Java to address complexity and to achieve speed.”

We don’t know anything more than “reference elements in 2 lists at the same index”, correct? We know FLOW can be used to do this. Java is not warranted at this point, IMO.

It is not known if the presumed speed increase (which is not a certainty because we don’t know what the iteration is doing) will matter. IME, it never has. I have never once needed to change FLOW to Java for speed. The time spent that could be reduced has always been elsewhere, not because something was coded in FLOW. (Side trip: we once replaced one built-in Java service with a custom Java service to address large lists, but have never switched a service from FLOW to Java.)

Perhaps but we don’t have info for that either. The OP may not know Java, or perhaps not well. IMO, Integration Server has seen success for the time that is has because one does not need to be a Java developer. It can be helpful, certainly, but it is not a prerequisite for success.

We agree that sometimes Java can be useful or even necessary. This thread has not reached that level of detail. Somehow we went from reading 2 lists to making suggestions to use Java in case things get complex or need to be faster Premature, IMO and too generalized.

When there is lack of information, isn’t it better to give insights rather then exact solutions? My recommendation towards java service has if statements, if you split the sentence by excluding that sentence out, it will break the context.

Try comparing string.split() and using a flow service within a loop/repeat to split the same string to multiple tokens once. You will understand what I mean.

The use case I had, was to split a UM message property to split search key and search values to populate a key value pair in MWS process search. I was supposed to implement this for every top level service calls. The difference between java and flow repeat was dramatic. It has been a while (6-7 years) so I don’t remember the exact values but it was like some less then a second to several seconds (depending on the number of tokens in the string).

The performance difference is well known against java service to flow service but I agree to you on most occasions. But there can be exceptions and this might be the case right now too. Imo its better to teach how to fish rather then giving away some fishes. Until we have more information its also pointless to argue about it

That is correct, speed is not a concern. Iterator solution worked as everyone suggested. Thank you!

Thank you, the $iteration works.

Another option is to not LOOP at all and instead use REPEAT. Using your own index var to reference both lists.

Hi, can you pls show me how to use the repeat as I have little to no experience in webMethods development.

Can you please show how to use the Repeat, I have little to no experience in webMethods development.