Since implementing Kinetic Cloud several years ago, I’ve been using a SysTask data directive to run some post processing on jobs generated by MRP. Specifically, the standard directive calls a function that retrieves all unfirm jobs and updates some UD/UserInteger fields on them that we use to make our custom job traveler reports easier to generate. Unfortunately, the effect of this missing data was not significant enough for our production planning team to notice during testing.
Now that we’re in 2024.1.10, we’ve discovered that data directives are no longer allowed on the SysTask table (as discussed here). Interestingly, this doesn’t seem to be a hard and fast rule, as Report tasks (at least the ones I’ve tested) are triggering the directive, however Process MRP tasks are not.
As referenced in the thread by @tkochhere, a post-processing method directive on RunTask might work. This is not working for me with the Process MRP task.
So… my question: is there another way to trigger a function or directive when a task finishes (or in this case, specifically when Process MRP finishes). I suppose I could use a BAQ and a scheduled function to poll the SysTask table for changes, although I would need to maintain some kind of state between runs to understand when a task moves from running to completed.
Back when I was originally trying to solve this problem, I tried a data directive on the JobHead table, since this is what I actually care about. However, the MRP process seems to populate jobs directly in the DB, skipping directives.
sure, you can create a task set, and put MRP as the first application in the task set. Then the second step would be to launch your Function. You can then schedule the task set to run every night.
I had thought of this, and will likely do this, but our production planning periodically will run MRP on onesie-twosie parts throughout the day and jobs generated by these also require post-processing.
This is a good solution when everything runs correctly. Process Sets lack the ability to run one task if the previous task was sucessful and another (or none) if it errored.
How could they specify the parts for MRP to run on? They are updating the process filter in the Process MRP form a few parts as needed. They aren’t doing a full MRP run throughout the day.
Knowing more about the update on the unfirm jobs would help. I am wondering if MRP has to be the trigger. Could you just leverage new unfirm jobs being created instead?
e: alternatively maybe PartPlant.MRPRecalcNeeded or MRPLastRunDate are reliable enough to use as triggers. At least for the onsie/twosie situations.
I think the process set takes care of your nightly MRP run, provided you have something set up to notify the appropriate people if it didn’t complete successfully.
This was what I ran into when originally trying to solve this problem several years ago. I just tested again with a standard data directive on both JobHead and JobMtl with a single Send Email block in both. During and after MRP completed, no emails are sent. With the same directives, when I manually firm or update the job (that MRP generated), the emails fire off just fine.
Thanks for the confirmation. Have the Epicor devs ever considered making it clear through the UI that a particular method or table is not BPM eligible? At best, it’s a tease of what might be possible, at worst it makes troubleshooting why my BPM isn’t working much harder.
I’ve resolved my particular issue with a pre-processing method directive on Erp.Rpt.JobTrav.SubmitToAgent. I’ve hooked into these methods for other use cases in the past, but realized this strategy might make sense for this problem too.
Since the additional data I’m populating JobHead with isn’t used for anything except the JobTraveler report, there’s really no need for it to exist until a report is requested. Calling my SetJobDetails function before SubmitToAgent runs seems to be working well. I’m able to use the “Jobs” parameters in the JobTravParam dataset that’s passed to specify precisely what job I want to set details on, so it’s actually quite a bit more efficient than my old way. Of course, this strategy wouldn’t work if the extra data was used elsewhere.
I still believe there is value in being able to monitor long running tasks for completion/errors and take an action (such as sending an email), and it is unfortunate that this ability has been removed.
That’s for the help everyone! It’s greatly appreciated.
Ah apologies, I missed that part. Is that just a cloud thing? I do it now on 23.x on prem and I am going to be pissed if they break my solutions (again).
