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.
As you can see I have only one message here, but it triggered 2 instances for the same data.
That null check only checks whether the list is empty, but it does not check or remove any null value items in the list.
Your configuration seems to be OK. How do you know the number of instances?
the null won't be an issue I guess, because the variable will receive either 0 or more items only.
Stefan Helzle said:Your configuration seems to be OK. How do you know the number of instances?
In monitoring I got an error stating that "The relationship between the task and the employee is already in the Data table" from a write to DSE node. Meaning the first instance wrote that relationship already, and the 2nd instance trying to do the same. using process display name I found this, 2 instances for the same data.
OK. And when monitoring the parent process instance, what do you see when right-clicking that sub process node?
It will always show 1 instances only, as I kept "Delete previously completed/cancelled instances"
OK.
So, to recap: You have a list with exactly a single item and expect that MNI node to run exactly a single time. But you see two process instances. This means, that either that list contains more than one item, or your observation, two process instances, is wrong. You will have to find a way to proof these expectations and observations.
I have never seen any misbehaviour when configured correctly.
What is the passed-in PV value in each child instance? You'll need to actually open the instances themselves - i.e. open the child process model and check the instances from there (since you have your node instances clearing out with every repeat, though i don't really think that's necessarily needed or a good idea).
I checked Mike, it's the same data in both instances. The first instance completed successfully, that's why for the 2nd instance I got this error "The relationship between the task and the employee is already in the Data table" from a write to DSE node.
this PV! is a map(multiple) type and you can see there is only one map value. That's why I can't able to find the root cause.
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.
Navin Kumar Selvam 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},
Navin Kumar Selvam 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
Navin Kumar Selvam 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.
Navin Kumar Selvam 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).