We’re finding that our CallContextBPMData fields are not holding their values in pre-processing of a directive if we have an external C# code reference. Has anyone encountered something similar?
Call context has a life time of (one) call and needs to be maintained by you client side particularly if it’s external
Hmmm … we’ve never had this issue versions prior to Kinetic though. As we work through our samdbox upgrade from E10, we are encountering issues with some of our BPMs where we stored data in the call context.
@josecgomez +1 … I remember in BPM training we were taught that the call context BPM data often persist after their use, although not guaranteed to do so. There were times when I would consume the value, then delete or overwrite it, to avoid further calls from falsely detecting a trigger. Looks like you hit one of those cases where the “not guaranteed” bites. And another reminder to test everything in an upgrade.
If I understand you fellows correctly … the call context was designed to be persistent only within the BPM. The fact that it was persistent within whatever UI the BPM was triggered from in prior versions was an unexpected side benefit that is no longer present in Kinetic. Lovely.
So, a question for you Bryan. Is there any reason not to upgrade the external dll to an Epicor function or take the opportunity to refactor the solution to make upgrades easier - like decouple with an API?
Yes, it’s probably not always very clear, but the CallContext is not a place to store or keep data.
It is meant to populate, call a BPM, and then be reused/reset/discarded.
It will keep it’s data for the lifetime of the BPM call, after that, nothing is guaranteed.
Think of more along the lines of optional BPM parameters.
Mark,
Unfortunately we have extensive C# content and we have multiple developers that each have their own AppServer workspaces where they compile code and check-in to a TFS server, which replaces the DLLs in the development environment. That then gets pushed up to the test environment and then to the live production environment after being thoroughly vetted. A remnant unfortunately from Epicor 9, and Manfact before it, where the custom code was written in Progress 4GL. The policy here is that it is easier to maintain multiple working environments and easier to port modified DLLs to the other environments, rather than having everything in server-side BPMs and using Solution Workbench.
We have started incorporating functions into our Kenetic sandbox instance, but only to call the external C# DLLs.
I can CERTAINLY appreciate the nice DevOps set up you have there! I would plug the “Make Kinetic easier to do DevOps practices” Idea, but that would be preaching to the choir.
We opened a case recently regarding - BPM Data Form not passing callContextBpmData.
Kinetic’s response: This was reported under problem number PRB0253777 and fixed in 2022.2.10.
We are on version 2022.2.9.
We are on 2023.1.6, so it would seem that patch addressed a related but not exact issue that we are encountering.
I know I’m wading in deep here, and might be pushing some buttons, but I promise there is no malice here.
If you have that level of C# expertise at your disposal, then there is no need to rely on Solution Workbench to manage your deployments. Just automate replacing the bpms and functions and ditch the custom dlls. It’s only going to get harder the longer you go.
You can keep your devops practices, but modify them to get rid of the garbage and work better with the ecosystem you are working in.
Some long overdue meetings might be in order.
Mark,
No worries.
We do not use Solution Workbench for the custom server code.porting. Checking in the code in Visual Studio to TFS writes the DLLs to the Development app server (of which we have only one). Then we have a manually-executed DOS batch script that copies the DLLs to the test environment app server, and another manually-executed DOS batch script that copies the DLLs to the multiple production app servers. For porting up new/modified Epicor artifacts such as BAQs, BPMs, external datasources, report definitions, menus, etcetera, we still use Solution Workbench.
I personally prefer having the code inside the BPMs and moving everything in Solution Workbench, as that’s how I worked in prior companies. But here, nine people have security clearance (and their own personal app servers) to modify C# code and obviously are not working on the same specific procedures simultaneously, so there had to be a way to compile and migrate up only modified DLLs. We have a global footprint, so we can only move DLLs to production on Saturdays and Sunday mornings ET (unless there is an emergency) because the app pools need to be recycled as well.
Regarding the “difficulty” the longer we go … yup, unfortunately. But we’ve been through this before. Migrating from E9 to E10 was particularly taxing because due to SysAgent not being able to handle multiple time zones properly in E9, all regions were in their own individual Epicor SQL databases on their own individual Windows servers. We unified into one SQL database while upgrading to E10. Fortunately with Kinetic, we at least have been able to use the standard Epicor upgrade tools. We are on our third sandbox currently, which consists of our E10 system upgraded to Kinetic 2023.1.6, and going through the testing process. That’s how we discovered this CallContext issue.
What I’m saying is, not really. Those dlls have to be called from somewhere, standardize
on how they are and replace them with function libraries. I would only drop to a dll if there
was something highly specialized that needed to be done.
Can’t unfortunately. It’s all specialized.