June,
In step #1, roughly how many different asset import groups do you have?
In step #2, are you selecting a single record or multiple records?
We have 37 asset import groups and selecting a single record
We don't actually use AssetImport where I work, but peeking under the covers in the Configuration Console LPL viewer has taught me something new that I didn't know (so thank you!).
Here is a screenshot of the LPL viewer for the PerformAssetInterface action:
What jumped out to me initially was the single constraint in the Entrance Rules. In most other scenarios in FSM the Infor developers would have coded that as valid when (IsNoRunningDuplicate) rather than an Entrance Rule + a constraint.
So that piqued my curiosity: do Entrance Rules get evaluated before or after you've entered parameters? I mocked up a silly test scenario as a User Business Class where I had two flavors of the same action, but one used a valid when and the other used Entrance Rules plus a constraint.
My testing showed that you can't even select the action when the condition is not valid (let alone populate any parameters), but that with the Entrance Rules (like here) you fill those out your parameters before the Entrance Rules get evaluated.
That's a long verbose way of saying that in your environment the IsNoRunningDuplicate condition must be false. Using the LPL viewer we can find the definition of that condition:
So this condition will be true when the RunningDuplicateRel relationship finds no records, and false when it does.
Scrolling down a little further in the LPL viewer we come to the definition of that relation:
Now it makes sense why they coded this as an Entrance Rule rather than a valid when: they need to know the name of the RunGroup (which is one of the parameters you enter).
If you go to the AssetManagementInterfaceResult business class you should find an existing record for that same FinanceEnterpriseGroup and RunGroup that has Status = 1 (Processing).
I'm not super familiar with this process, but looking at what the LPL in AssetManagementInterfaceResult does, there's quite a few things invoked via async in the background. So you might check in Async Admin whether one of the actions related to this RunGroup's import either failed or is blocked waiting on some other synchronized action or something like that.
As a work around you should be able to interface a new group using a new never before used RunGroup name. With a brand new RunGroup name there won't be any matching records in the AssetManagementInterfaceResult business class, so the RunningDuplicateRel in AssetImport won't exist which will make the IsNoRunningDuplicate constraints in the PerformAssetInterface action's Entrance Rule be true, thus satisfying the condition.
Clear as mud? (If it isn't clear, let me know and I'll try and rephrase things.)
To any Infor FSM developers who happen to read this, it might make things more clear if you changed the error message to read: "AssetInterfaceAlreadyRunningForRunGroup<PrmRunGroup>". (My addition to the existing error message being the part in bold.)
Actually, looking at the first screenshot again, they default the PrmRunGroup to the value of the persistent field named RunGroup, and it is the value of the persistent field that is used in the condition & relation, not the parameter. And the action doesn't set the RunGroup to the name of the PrmRunGroup. So what you enter on the parameter form really will never get used it seems. (That feels buggy!)
So to get a new run group name you'd need to update the persistent field itself (via an Update action or ISD, etc.)
And my suggestion to any FSM developer lurking here would need to be modified to reference <RunGroup> rather than <PrmRunGroup>.
