Came across an issue and not sure if this is a generic feature of epicor, or… somewhere, I am making a mistake.
To Summaize –
I have created a Data Directive (Standard) BPM which triggers:-
Towards ShipHead
If a particular UD field has changed from False to True
Calls a Custom Code which adds additional info to the ShipHead
For the sake of simplicity, lets call this particular UD field MYCOLUMN
When in a Customisation:-
I check/tick the UD (MYCOLUMN) field on the screen
click Save
I then click ‘Refresh’ when additional information (from the BPM) is added
WORKS
When I call a Epicor Function:-
Simply sets the UD (MYCOLUMN) field to true
Applies this using UpdateExt Custom Code
After the Function call, the MYCOLUMN field is set to True
However, the BPM was not triggered. The additional information has not been applied
DOES NOT WORK
What could be the cause of this? I would assume this would be a huge bug if Epicor’s UpdateExt did not trigger BPMs. (I read somewhere it calls Update, anyway)
With this, I am likely doing something wrong… but I don’t know what. All I am doing is calling UpdateExt with the UD field set to true. This should call the BPM.
I don’t think standard directives have a lot of the data in them that an in-trans directive will have. It probably isn’t picking up that a field changed - therefore won’t trigger. That’s my first suggestion. Re-create your BPM as an in-trans data directive.
Thanks for responding. The BPM I am trying to create is going to be a bit more complicated than the one I created for testing purposes. Therefore, the proper BPM will have to be Standard, not In-Transaction.
Moving away from this, it seems bazaar that the BPM is triggered when I made changes via Customisation… but not using an Epicor Function (which is just setting the field to true and calling UpdateExt)
It should trigger the BPM. What is so different compared the the Customisation? The only thing I can think of is the Customisation calls Save (and I am sure other Methods which could be found via Tracing)
But the BPM should trigger for UpdateExt as well, right?
I agree. I’d expect them both to work or neither to work.
One thing I need to keep in mind is that I know virtually nothing about functions. It’s a new concept to me and I’m not sure what’s all involved to set one up properly and invoke it.
Also, one other tidbit… you can invoke a standard directive from an in-trans one if it needs to be triggered by something that you are not seeing in the standard type. It may not help you in this case, but put it in your toolbox. I believe the widget is called “Enable Standard Directive”. Then on the condition block in the standard directive, you can specify when it’s enabled by a specific BPM as a trigger.
UpdateExt bypasses a lot of the BO logic and just shoves the data in. I am not surprised that this is happening. I would use the Update method instead.
It just seems like a HUGE oversight with UpdateExt. You imagine various approaches to solving problems (as well as Service Connect, etc) using UpdateExt, only to find a new BPM that has been created is only triggering some of the time.
Seems like UpdateExt should never be used under any circumstances, just because of potential BPMs being used in future.
If I am correct, the UpdateExt was created to provide an easier way to do an integration, so they were intentionally programmed to bypass BOs and triggers. If you want to make sure BPMs are triggered, you should be utilizing the trace and recreating the appropriate calls. UpdateExt is a shortcut that should only be used when the integration being created is by someone who has no access or no knowledge of the Epcicor structure.
Think about it this way. You buy a new software program and want it integrated to Epicor. The software vendor does not own a version of Epicor and has never used it. How are they going to fully integrate their software? They can’t so UpdateExt was created to allow a dump of data without having to understand Epicor.