We are web only. I have a shipping notice that fires from a bpm in customer shipment entry. Basically i have a custom code widget that builds an html email, and I jam that string in context data char 05. In version 2025.2.7 and before, this worked fine, but now they are populating all of that data in the header, which causes the ui to bug out. Everything still works, I get the ship notice, but now i get a lovely 404 error in a slideout as well letting me the header is too big.
Before:
After:
There are some posts about with the exact limit, i think it’s 48KB? 64KB? i forgot, but it sounds like you are exceeding that and will need to pass the data another way (or zip it before you send it and unzip it on the receiving side!)
I was able to work around it, all is well I guess. The part of this that is a bit upsetting, is because we’re cloud, our pilot environment updated on Tuesday, and this was in production on Saturday. This change isn’t documented anywhere, so how would I know to test it? Or are we expected to test every customization with a 4 day notice?
The most frustrating thing about cloud, is so many things break on every release, no matter how “minor” it is.
Putting aside that this is an HTTP limitation and it was discussed on this forum back in Sep. 2024, if you worked at Epicor, where would you document this?
I think there is a place for all of us to use automated testing to reduce our time to test. It will not cover every eventuality, but it should check for regressions for problems we have seen previously.
Right here. Everything that has changed in the release should be in the release notes, which we already have access to.
Like @Mark_Wonsil linked to, its always been passed through the header, that part isn’t new. Likely some other change they made slightly increase the amount of information being sent in the header and so then your email body was enough to put you over the limit. So even if it was/is in the change log, it might have required some detailed thinking to realized the side effect it might have.
I disagree, the screenshots above are the exact same BPM firing, the top one on 2025.2.7, the bottom one 2025.2.10
What BO are you using?
Maybe that particular BO did not pass context header that way before but received a patch to do so in this version.
OK, fair enough. What payload was it passed on in 2025.2.7 then? I see the field is in the header, even if it wasn’t filled so I would say its what they were intending.
You’re welcome to, but something is wonky. The CallContextBPMData has been in the header since the move to a REST backend, which was a looooonnnggg time ago.
Lol I’m not really here to argue with you all, it was a custom code widget that set callContextChar03 or whatever directly. Also we are web only and not on prem? Not sure that matters.
Also this is really not an issue any more. I fixed my code, it probably wasn’t smart to just use whatever random variables or what not I had lying around to make things easy. I can totally see how not having the data in the callContext is a bug, and not the other way.
The only thing I was really trying to say, is the lack of documentation to point at what is changing is frustrating. It would nice to be proactive on things for once with Epicor instead of reactive.
No argument about the frustration 
Yeah, not trying to argue with you either.
The example I remember was someone using CallContext as a debug text holder. It was failing sporadically. Turns out, they were continuously appending debug text and eventually overflowing the header. This of course was not an issue for net.tcp.
Back to the original question on where to post this kind of warning. There is no fix version since there is nothing to fix. The Function Area is…Tools and Technology? I’m just not sure this is the place. Maybe the BPM Cookbook or something similar?
