So the flaw in the solution presented by epicor is that the resulting CallcontextBpmData file doesn’t get created with the same tableguid that the other report tables have?
I don’t really know what is happening behind the scenes. Just know that there are no records to reference when I try to reference that table in my rdl.
Correct. The CallContextBPMData table in Reporting Services is empty, only when calling the report from the web. Calling it from the client works just fine.
This is obviously a flaw in the web portion of Kinetic.
edit: I accidentally said calling it from the browser works just fine.
1 Like
If you attempted the Epicor “solution” using a function, are you able to look through the list of CallContextBpmData tables, in your report server, and see if there is one with the current creation date – not the one “created but empty”. I just wonder if one is being created with another tableguid value. If it is, then the problem persists and Epicor’s solution is essentially useless to those of us with SSRS reports.
Cloud customers are not able to access the report server . . .
Right, we have plans to move to the cloud next year, in the meantime we are testing Kinetic through the browser (our data is on prem).
The issue with CallContext BPMData not persisting as expected has been corrected and should clear QA in the next day or so. Retrofits for 2024.1.19, 2024.2.4+ have been requested.
9 Likes
Thank you for the update!!
@Rich are you aware of any progress on this issue? One support tech told me a fix is available, another told me no, there is no fix available yet. As its been over a month since you advised its fixed, is there any eta when the fix will be available to us? This continues to be a critical gap in functionality for us.
1 Like
Hey Alisa - this issue shows as fixed and in your Production environment - your Pilot and Additional systems are running an older hotfix version and do not have the correction. Please contact Support and request that your Pilot and Additional environments get updated to the latest container image.
1 Like
Amazing! I will test it out, thanks!
Unfortunately it still doesn’t seem to be persisting the values in CallContextBpmData.
1 Like
Hotfix is working in Pilot. Not sure what they installed as the other tech is insisting there is no such fix.
1 Like
Escalate
1 Like
I’m in 2024.2.12, and if I print a packing slip from the smart client, my callcontextbpmdata populates as expected.
However, if I try to print a packslip from a function or an advanced Baq, using either RunDirect or SubmitToAgent, it does not populate.
Edit to add, doesn’t matter where I run it from, if it’s my code, it doesn’t work.
WTF, I thought this was fixed, or is there a regression?
How the hell does it work in the client? I’m using the same damn method.
5 Likes