I have a somewhat complex method directive which manages two date fields which we have on our Order Entry screen: Pick By Date and Ship By Date. Each field has a dedicated section of C# code to handle its unique properties and requirements. I am currently using a string variable (infoMsg) and as the code progresses through the two programs, the string is appended with brief statements which I want the user to see in a single Message.
This might include whether the date(s) encountered falls on a Saturday, Sunday or non-work day on the Production Calendar. We also have a UD field to specify Cutoff Times for each of our Ship Via’s so if an order is being placed after the truck leaves the premises, a day is added to the result, and infoMsg is appended with something like “FedEx Ground has a Cutoff Time of 2:00 pm, therefore, the Ship By Date has been adjusted to the next business day.” There are several other rules such as the Pick By Date cannot be after the Ship By Date, etc.
I’ve thought about using a mathematical solution where I set an integer variable to increase by 1, 2, 4, 8, 16, etc. as it encounters the various scenarios, but this can quickly get out of hand when de-cyphering the final result into a well formed message.
Another idea would be to use a DataSet instead of a string, and populating the rows with the various messages, then using a foreach with StringBuilder to make the final message content. In fact, I could create a UserCodes list of message ID numbers, and translate the IDs into the final message.
What’s the end-goal here? It sounds like it’s to create a narrative to show the user about what happened and why?
My cursory understanding evokes thoughts of an overengineered solution to a relatively simple problem. Sounds like you’re taking some facts and comparing them to certain rules, and based on the combination of facts and rules you will present a tailored message back to the user.
I’d say the complexity in this is the logic rather than the message back to the user. How many potential scenarios are we taking about here?
Is it truly a dynamic message every time or is it more of a set of potential messages with fill-in-the-blank variable values?
If you’re doing the manipulation in custom code, are you also popping the BPM info message or are you using a separate widget for that? 2 ways, either pop the message from within the existing code if required, that way you can build a string with any relevant error messages. Or set a BPM Call Context field to hold the string that you build, then still use a widget to pop it up.
Also I thought I’d share a different way to approach the same issue of raising issues to Order Entry person:
See there are a couple of extra grids in the top half of the screen. The Order Checks one is running a separate BAQ for each “Test” case - so you could have 2, or more. I’ve created a few:
Aaron, I believe your assessment of this being overengineered is entirely correct.
Truth be told, I was primarily interested in learning alternative methods for approaching this type of scenario. I took some time to re-evaluate what it was that I really needed to communicate with the end-users, and ended up using a shared integer so I would be able to suppress repeating the same message from both Ship By and Pick By date calculation programs.
