Hello fellow Snaplogicians,
I am working on a pipeline that must read in 1 to many rows about a single entity, each one sequentially, and apply the results to a single document. Each row may not change the document, but represent a possible change.
Generating the initial document is easy enough as I can select the first entry of the table, but generating the subsequent entities is trickier as there could be 0 more entries, 10000 more entries, etc.
Example basic pipeline pictures. The pipeline in the image, and the one I have been working, will not prepare when the second input to the union is connected, in both validation and execution. This would seem to indicate that this type of operation is not allowed/available, regardless of whether it would function.
In this image, the selection gets the first edit of uniquely identified objects as its own document, each object has its own set of changes of 1 to many. It converts that into a common object. It then enters the loop, where it gets the next edit of the object. If no other edit exists for that distinguishable object, that object alone is removed and the loop and will not be processed anymore. If there is an edit, it is compared to determine if there was a change conducted on it that should be applied to the document.
After the determination, the document is mapped back to match the common object with changes applied. It then re-enters the loop and gets the next edit.
This is repeated as long as one document has anther edit to retrieve. It essentially is a loop which if implemented in Java (or other language) would be easy enough, but within Snaplogic causes issues.
So the question is, what are the alternatives to do this within Snaplogic exclusively without outside resources?
This seems like it would be a powerful tool if loops like this were allowed, it would open up a possibility of non linear processing, but perhaps there is something I am missing here that would enable similar functionality without the need for a loop.
An alternative might be to call a child pipeline, but would need to send in the object, and could be many calls.
Another alternative may be a nested child pipelines? Where the object is passed in, and continues down through children until there are no more results for edits to the object. But this would seem costly as there could be millions of child pipelines being executed.
Any ideas here? If something is lacking explanation I am more than happy to elaborate.
Thanks!
