@josecgomez and anyone else who may know…
I am creating a BPM for Quote.CreateOrder and I need a value from the PreProcessing BPM to be available in a PostProcessing BPM. Should I use CallContextBPMData, or is there a better way?
Additionally, if I use CallContextBPMData.Number01 and set its value in this method, can it be changed anywhere else in Quote for example Quote.Update or is its value only in the scope of Quote.CreateOrder?
Thanks in advance for any help.
Respectfully,
Utah
Yes use that, that value is available within the same screen/ module so all calls to quote within the same module / session would have that value available
@josecgomez just to clarify, if Quote.Update was called at some point after the Quote.CreateOrder, any BPM in the Update method would have access to CallContextBpmData.Number01 that was set in the Quote.CreateOrder method, correct?
As long as you are in the same screen
Is this an appropriate way to pass values between the nodes of a data directive? I tried to use a variable, but the AutoPrint node can’t use variables to control the number of copies, only values from CallContextBPMData or database tables.
What’s the scope of CallContextBPMData values in a data directive? Do I have to examine all the BPMs that could be triggered on the same screen to ensure that I don’t overwrite a field being used by something else?
The CallContext tables are initialized at the Service boundary - meaning that the Service is expecting the data to be coming from the Client. If the Client does not send it - optional in REST calls for example - I believe that the BPMData table is initialized to an empty row.
BPMData then persists through the life of the Service / Method call. If the code in the method updates multiple Records / Tables the same instance of BPMData exists in any Data Directive on those Tables and values set in any earlier touch point will be available in subsequent touch points.
BPMData is then sent back to the Client. The Epicor UI will persist that data for the life of the Instance of a UI Form. As a result, the data in BPMData can be adjusted on the Client or on the Server in the BPM Method and Data Directives. Non-Epicor Clients (REST) generally do not persist the data from one Method call to another but could - that behavior is up to the consumer of the Epicor Services.
The BPMData table is also used to store the data entered in the BPM InfoPrompt Forms. Because of that, it is possible for you to pre-populate the BPMData fields filled from an InfoPrompt so that you do not need to “pop” the InfoPrompt - useful when you are attempting to automate a flow via Service Connect where a method has an InfoPrompt for additional user input.
Epicor expects the BPMData table to contain only a single row and that row - with the exception of usage in the InfoPrompt Forms - is not managed in any way by Epicor.
The CallContextBPMData row in context when a Report is submitted, is also written out to the Transient Table Set in the Reporting Data. With that, you can prompt for data or pass data from the Report UI for use in Report Generation (in the RDL or RPT).
Thanks, Rich. So if I trace the method that triggers the data directive, and the trace includes this:
<parameter name="CallContext" type="Ice.Bpm.Context.ContextDataSet">
<ContextDataSet xmlns="http://www.epicor.com/Ice/300/Bpm/Context">
<BpmData>
<SysRowID>00000000-0000-0000-0000-000000000000</SysRowID>
</BpmData>
</ContextDataSet>
</parameter>
…does that mean it’s not being used at all, and I’m safe to use any field?
Most Likely. The UI Trace is only showing the outbound version of the BPMData but since the Client will Accept the BPMData table value back from the Server and then use it on the next call to the Server, you would likely see something besides SysRowID in the trace.
It is theoretically possible that it could still be used on the Server between touch points and then “cleaned” before coming back to Client but that is pretty unlikely.