Unable to write to CallContextBpmData when using Kinetic in browser.
We make use of the CallContextBpmData table to store codes which an SSRS report uses to respond to specific scenarios. This works well in Classic. In Kinetic we are able to create a layer whereby we can write to the CallContextBpmData table by overriding the SubmitToAgent process, and this works using Kinetic (in Windows), but does not work running Kinetic through the browser.
You might be trying to use it beyond its intended functionality… Are you setting it right before the BO Method called?
3 Likes
Yes, we are setting it just prior to the BO call. The thing is that when we go to create an SSRS report via Report Style - the table is created with a tableGuid in our Report Server database. And it works for us when using Kinetic, just doesn’t work with Kinetic via a browser. via the browser the table CallContextBpmdata_tableGuid is created, but with zero records.
1 Like
I’ve never defined my own columns in the callContextBpmData … I didn’t even realize it was a thing 
We aren’t really defining our own columns, but rather using the existing fields (in our case Character01) to contains a code value. Since Epicor creates temp tables for the use by SSRS, and CallContextBpmData is one of those tables created. It is convenient to make use of it for sending specific data (unavailable from the Report Data Definition created tables).
1 Like
@Blair have you found a way around this? We have several reports that are using Checkboxes found in CallContextBpmData to customize how SSRS will display the report.
When calling the report from the client, it works perfectly, and has for years… CallContexBpmData is an available dataset on many prepackaged reports.
However, when calling the exact same report from the browser, the CallContextBpmData table is empty.
You’ll want to set the field with a row-update before the call.
I’ve also not seen things persist in CallContextBpmData from App Studio
In an event that triggers before MasterUpdate on SalesOrder, I set my field with row-update, then see nothing in CallContextBpmData in the SalesOrder.MasterUpdate / Update BPMs
The only time I have successfully used CallContextBpmData in Kinetic is when setting it in a pre-process BPM and checking the value in a post-process BPM for the same method…
CallContextBpmData is only guaranteed to persist for the current call chain.
Say you set it and call a BPM, and that BPM calls another one, and etc, etc, that will persist until it returns.
If multiple methods are called from the client itself, there are no real guarantees.
Mark, the issue re: CallContextBpmData not retaining values has been raised with the folks at Epicor. There are 2 potential solutions, 1) if you calling the report from a list of Report Styles (say OrderAck or PackSlip report styles) – in our case we created a single SSRS report to produce multiple related reports – SSRS reads the Report Style code value and adjusts the report accordingly (say one report shows all related taxes/shipping costs and another one excludes those – the report style code is used by the SSRS report to do that) The report style code value is stored in the temp table “RptParameters_tableguid”. 2) if you are sending multiple criteria (yes/no, date ranges, territory selections) then try creating a Report Data Definition based upon a BAQ (which has parameters, defined for your criteria, and then in the RDD create a report criteria set based upon those BAQ parameters). When you go to run the report, you enter the parameters – those parameters are then saved in a “usercriteria” field in the temp table RptParamters_tableguid. In your SSRS report you would then parse out the criteria values from the “usercriteria” field and use them however you want in your report.
1 Like
Mark, the issue re: CallContextBpmData not retaining values has been raised with the folks at Epicor. There are 2 potential solutions, 1) if you calling the report from a list of Report Styles (say OrderAck or PackSlip report styles) – in our case we created a single SSRS report to produce multiple related reports – SSRS reads the Report Style code value and adjusts the report accordingly (say one report shows all related taxes/shipping costs and another one excludes those – the report style code is used by the SSRS report to do that) The report style code value is stored in the temp table “RptParameters_tableguid”. 2) if you are sending multiple criteria (yes/no, date ranges, territory selections) then try creating a Report Data Definition based upon a BAQ (which has parameters, defined for your criteria, and then in the RDD create a report criteria set based upon those BAQ parameters). When you go to run the report, you enter the parameters – those parameters are then saved in a “usercriteria” field in the temp table RptParamters_tableguid. In your SSRS report you would then parse out the criteria values from the “usercriteria” field and use them however you want in your report.
There are several threads on this issue and it is a bug - EpicCare problem references - PRB0226260 and PRB0262305. I have requested escalation on the correction.
The BPMData values submitted with a Report are designed to persist all the way into the reporting Transient table set so you can use custom data entered on the Report Submission form to include in the report or for custom filtering within the SSRS RDL.
9 Likes
Thank you Blair. For one of our clients they were ok with the solution of duplicate reports. For the other client, we will have to wait for Epicor to fix the bug since we have many fields required to go through CallContextBPM.
This came up today in a CR Call. We have mentioned the PRBs Rich mentioned.
3 Likes
Are there any updates on when this will be fixed? I have bugged support numerous times and they are unable to provide any ETA or targeted release. This is a huge problem.
5 Likes
Just adding my support. This is important.
5 Likes
According to my PRB number, it says its “Accepted - Not Yet Planned”
Really need to light a fire under the dev team.
3 Likes
Right me too, needs to be planned. There is no workaround and this is critical functionality. This is a huge blocker to moving to kinetic.
1 Like
I received the following, potential short term solution from Epicor.
-
Instead of using CallContextBPMData to pass on additional information to the app server
-
Create a Library and A Function
-
The function should have the same parameters and SubmitToAgent – AND any additional parameters you need to cover the CallContextBPMData changes you want to make.
-
Modify the Event that Calls SubmitToAgent to call your function instead
-
Then you can either have the function itself modify the CallContextBPMData and let the BPM on SubmitToAgent continue as is, or you can have it doe whatever additional work I s needed and get rid of the BPM.
Note - we haven’t tried this solution, we rely upon the style code in the RptParameter_tableguid table to provide the codes for our reports.
If anyone tries out the above option, please post your semi-detailed solution.
1 Like
I don’t understand. The bug is that the callcontextbpmdata simply isn’t there when you try to reference it in the rdl. It doesn’t matter if you populate it by binding in the layer or through a function, the problem is that the data set just isn’t there.