Standard Data Directive Disables Triggers

Epicor ERP 10
,
1

We have a Standard Data Directive on the JobProd table that does updating on the JobMaterial table. I noticed in the server trace file that before it fires the standard directive bpms, it disables all triggers. I’m curious to know why and is it save to enable them manually and then disable after the bpm is done? Any thoughts?

I’m showing the JobEntry trace file but I see it on other methods such as ABCCode.Update too.

<Op Utc="2020-05-14T21:02:55.3566290Z" act="Erp:BO:JobEntry/JobEntrySvcContract/Update" dur="120.0843" cli="" usr="calebg" machine="" pid="13008" tid="41" xmlns="">
  <Trigger table="JobProd" type="Modified" pk="JobProd&lt;~&gt;0b55dd24-3018-4af5-96b9-9c35a18792a5" rowId="0b55dd24-3018-4af5-96b9-9c35a18792a5" duration="2.8501" runningTriggers="Modified JobProd 0b55dd24-3018-4af5-96b9-9c35a18792a5 --- " />
  <BpmCustomization Source="DB" BpMethodCode="Erp.JobProd" Type="In Transaction Trigger" Duration="0" />
  <Trigger msg="Disabling all triggers." />
  <BpmCustomization Source="DB" BpMethodCode="Erp.JobProd" Type="Standard Trigger" Duration="89">
	<BpmDirective Type="1" ID="06446010-e311-4951-bc8e-ac9d95c7d9f3" Name="Debug" VisibilityScope="0" Duration="89" />
  </BpmCustomization>
</Op>
2

I believe that STD Directives disable so that you dont get circular triggers.

3

So what would be the proper way or best practice to update a table that has triggers, such as JobMtl? I’m updating the warehouse code when the demand link warehouse code changes, and from the looks of the trace file, multiple tables get updated when JobMtl.WarehouseCode is updated.

I did move it to the In-Tran and the triggers are fired like they should. I just thought it would safer to use the Standard than the In-Tran.

4

standard is better because an in-trans can be cancelled by a subsequent in-trans BPM. Standard is triggered AFTER all the work is done, so you can normally trust that at the Standard BPM, any other work you need to do can be safely executed. BUT if the Standard BPM does any data updates, it will not cause any other BPMs to trigger… note that you are not allowed to call any methods with widgets in a Std Data BPM… it IS POSSIBLE to do this in c# code, but any BPMs that are normally triggered will be disabled.
Best Practice? well… My rules:

  • Make sure you dont break anything
  • Make sure that your BPMs dont take a long time to run
  • Make sure that you are not doing unnecessary data reads (making it inefficient).

That said, I have made some pretty complex BPMs that do some tricks. One trick is to cause an intentional cascade… example, inside a Data BPM for customer, you can call the ABCCode.GetNew process, and have a METHOD BPM that is triggered off the GET NEW… when you do this, the ABCCode becomes a separate call that is not under the control of the Data BPM, and it can do more stuff that is not related to the ABC Code. I have built entire customizations around the TIP.Update process, passing complete JSON Datasets to TIP, and then TIP reads the JSON, which then does more work for me (sort of like a service). Is this “Best practice”… well… it follows my rules. but now that Epicor Functions are fully working, the need for this type of trick will be unnecessary.