Scheduling ERP Processes

Batch processes have been with us since the inception of business computing. You can complete a batch of tasks as a single process for sake of efficiency. The benefits of such processes are clearly time-saving for an Epicor administrator. Batch processing allows for the automation of many tasks that would take an actual user an immense amount of time and effort to perform in order to accomplish the required manual tasks and calculations. In ERP software, the Materials Requirements Planning (or MRP) process is probably the most well known of such processes. As ERP systems have become more advanced, the need to group multiple processes to operate in harmony has become increasingly important.

Epicor Process Bundling

In an Epicor context, there are many processes that you might want to sequentially bundle, such as following up an MRP regeneration by running the production planning and the shop schedule load graph processes, such that you can see the implication of the MRP run on material shortages and shop load respectively.

Sounds simple enough, but the problem with this scenario comes with the fact that such processes often run in the wee hours of the night, and only the most zealous members of the ERP fandom would wish to set their alarms for 3:00 AM so they can manually kick off a few ancillary processes once the MRP regen completes.

Enter Epicor’s Process Set Maintenance. Epicor process sets allow Epicor admins to bundle process runs into a single event. This allows you to sequentially run a suite of Epicor processes automatically, without human intervention. Process sets can include various differences:

• processes
• reports
• executive queries

Once a process set is defined, and then attached to a system agent schedule, the related tasks are automatically processed according to the timing defined by the system agent.

Let’s look at a common issue, one that surfaces frequently for an Epicor admin. At times, you may wish to run processes in a manner that filters the actual processing. For instance, you may wish to run MRP by site, or PO suggestions according to a handful of part classes. Confusion is commonplace in handling process sets when the processes involved possess filtered activities. I’ll give you an example of the problem and an explanation of the actual behavior an Epicor admin can expect to experience when setting up and executing a process set.

Epicor Process Set Maintenance With Process Filters Enabled

Creating a process set occurs through the Process Set Maintenance screen. Once a process set is defined, individual processes can be assigned to a process set. In the example below, I created a process set:

Next, I opened the PO Suggestion screen and configured its process parameters. Of those parameters, I set a site-specific filter:

Then I clicked the icon below to save the PO Suggestion process to the process set I previously created:

Returning to my original process set, I now see that the PO Suggestions process has been attached to the process set. Were I to go through the same actions with other processes, I could add multiple processes to this process set, and then use the “Move Up” and “Move Down” buttons to order them appropriately. But one point of confusion exists here. If I were to double-click on the process that I just added, to review its properties, the filter that I previous defined is no longer visible:

As we will see, this cosmetic issue is not detrimental to the actual execution of the processes themselves. To complete the setup of a process set, you need to assign it to a System Agent Schedule. This is accomplished through the Schedule Process Set screen. From this screen, you can select the Process Set:

Allowing the System Agent schedule to run according to its next run time, I can see in the Epicor System Monitor that the underlying process ran successfully:

Looking at the Log File related to the PO Suggestions run, I can see that the PO Suggestions process ran according to the filter that I had initially set. As you can see, the log file indicates the Epicor site that I had defined:

Epicor Admin Automation

In summary, while it may appear that an Epicor process loses its configured filters when added to a process set, in actuality, these parameters are retained, allowing the Epicor Admin great flexibility in automating a variety of ERP system activities.

Epicor Consulting? Epicor Managed Hosting?

Get advice from an ERP consultant or managed IT specialist. Chat with us to get a free ERP consultation or technology assessment.

Fortunately, there are a number of steps one can take to cancel or complete a stuck task.

When troubleshooting a stuck task in Epicor, look to address it in the following order:

• Cancel the task in the System monitor
• Bounce the Task Agent
• Bounce the AppServer instance
• Update the rogue SysTask record directly in SQL

Cancel the Task in the Epicor System Monitor

The simplest way to kill a task is using the Epicor System Monitor itself. This can be done by navigating to the “Active Tasks” tab, selecting the task you intend to cancel and clicking the delete (“X”) icon. If successful, this task will fall out of the “Active Tasks” queue and fall into the “History Tasks” queue as a task with a status of “Cancelled”:

Bounce the Task Agent

If the task will not cancel through the System Monitor, you can try to bounce the Task Agent itself, which may free up the task and allow it to cancel. This is a relatively noninvasive method and will generally go unnoticed by the user community. From the AppServer, launch the Epicor Administration console, and from the Admin console, launch the Task Agent Configuration utility. Select the task agent you wish to cancel and from the “Actions” menu, select “Stop Agent…”:

Bounce the AppServer Instance

If a Task Agent bounce is ineffective, bouncing the AppServer itself may work. This is a much more invasive solution, so it should be done when the user load is low, or else at a prescribed time such that the user community will be prepared. From the Admin Console, navigate to the server you wish to bounce, right-click the server node and select “Stop Application Pool.”  Once stopped, right-click it again and select “Start Application Pool.” In my experience, this will normally shake loose the stuck task:

Update the rogue SysTask record directly in SQL

If all else fails, your last recourse is to update the SysTask record through SQL Server. Opening an instance of SQL Server Management Studio, navigate to the Database in question and create a new query. Enter the script below, adjusting the SysTaskNum to reflect the specific task number as found in the System Monitor. Run the query to update the record. While I am never a fan of direct SQL updates, this is one case in which such an update may be necessary.

update ice.SysTask set EndedOn = GetDate(), TaskStatus = ‘Complete’, History = 1 where SysTaskNum = 55228
delete ice.SysTaskKill where SysTaskNum = 55228

The Epicor System Monitor Lets You View, Manage and Cancel Tasks

At times, Epicor tasks need to be stopped. Hopefully, this article helped you understand the steps to take when trying to kill a task. This Epicor screen shows you which tasks are active, and it enables the initial steps for task resolution. You might even use this ERP feature daily. Due to its usefulness, the System Monitor is a classic. If your ERP system is a labyrinth, then your Epicor System Monitor is a golden thread, helping you navigate the maze and kill the wrongful task. As I’ve always said, it’s better to monitor than to minotaur…

For more ERP tricks from our Epicor consulting team, ask us for a case study on CTO and ETO implementations.

Or click here to watch our Epicor Summit to learn about Planning Workbench, SQL Server Administration, and SSRS Reports.