Hello Team,I'm using a MNI startprocess with the Run one instance for each item in pv!array (spawn all) along Run all instances at the same time(move when All instances are done), in process parameters I'm sending pv!array[tp!instanceindex] to another process.In one scenario I have only one element in pv!array, but it triggered 2 instances for the same data. Could anyone explain me why this happening?Stefan Helzle
Mike Schmitt
Discussion posts and replies are publicly visible
Have you posted any image ?
May be the array contains null value. Check the size of array.
I checked in process history, I have only one value inside that array and I'm also having xor to check the null values.
what's the value of the PV in the parent process? how sure are you that there are no duplicates and no null entries? can you post a screenshot of the PV value?
As you can see 2 instances are triggered at the same time
Based on those 2 instances timings, I checked the history in the parent PM, Pv!messageswithmatch is map(multiple type), as you can see it has only one value(a single map). How I confirmed that: if the pv! has a null value, it should have a comma after "}". so we can confirm there is no null.
Coming to those 2 instances history:As you can see that both has same values. that means the MNI triggered twice even though it has a single value.In worst case assume if the PV! has a null value. I'm using tp!instanceindex for indexing variable in the MNI node, then the child process needs to receive an null value right. but here it is not the case.
Unknown said:How I confirmed that: if the pv! has a null value, it should have a comma after "}". so we can confirm there is no null.
I checked this in a dummy process. I passed {a!map(a:"h"),null} in process variables you can see that {a=h},
Unknown said:if the pv! has a null value, it should have a comma after "}".
yes, that's usually what i would assume as well.
I just had an idea, could it be that you have more than a single flow going into that node?
I have seen juniors mixing up their models by trying to drag&drop nodes and connectors from one place to another, building loops and other unwanted connections.
Move your nodes around and check that please.
Stefan Helzle said:could it be that you have more than a single flow going into that node
good point - it would be helpful for Kumar to post a wider view of the process instance in question, particularly since the instance snippet already shown shows multiple paths have executed already.
I have only one incoming path for that node
Unknown said:I have only one incoming path for that node
AFAIK it's less about the potential number of incoming paths, but rather a potential number of incoming executing process flows (like for example if a prior node in the same flow executed by MNI and ended up sending 2 separate flows to the "matches found" XOR, which both take the "Yes" output, they would then both kick off the ProcessMatch start process node.)
These nodes can overlap in a way you will only spot them if moving nodes, or even deleting connectors.
Is that really possible, a MNI node will execute a prior node once again? if yes how to avoid that?
Mike Schmitt said:if a prior node in the same flow executed by MNI and ended up sending 2 separate flows to the "matches found" XOR, which both take the "Yes" output, they would then both kick off the ProcessMatch start process node.)
Well, we do not know what your model is doing and how it is designed. From the screenshots, it is hard to say.
But it works as designed, and if you want to make sure that there is only a single flow into that node, you have to configure any previous node so that it does not create multiple.
Unknown said:a MNI node will execute a prior node once again?
i'm saying (for example) if a prior node in this process flow (since your screenshot is not comprehensive, i have no way of knowing) executed 2 flows that continue through the portion we can see, it would kick off the mni "start process" node twice (each instance executing once per the size of your PV array, but still launching 2 instances in total).
Yeah it would be really helpful if you posted the full screenshot of the process model. In general in these scenarios I have seen that when you drag a node away from it's current path, you might end up with overlapping paths (e.g. a path directly from your script task to the start process node and a path that goes through the gateway.