SyteLine Background Task Definitions explained

Short answer

Every report, utility or process that runs in the SyteLine background queue has a record on the Background Task Definitions form. The record names the task and says what it runs, with an Executable Type of RPT (a report), SP (a stored procedure), EXE (a program) or IDOMTH (an IDO method). TaskMan reads this record when a task is submitted and runs the matching executable. If you need to know what a report really runs, or want to run your own code in the background, this form is where you start.

Why this form matters

Most people never open it. It becomes important in three situations:

A report is slow or broken, and you need to know which stored procedure or report it actually runs.
You've built something custom, such as a report, a cleanup procedure or an integration program, and you want users to run or schedule it like any standard SyteLine task.
A task fails and you want to understand what TaskMan was trying to do.

The four executable types

Executable Type	Runs	Executable Name holds	Typical use
`RPT`	A report	The report name	Standard and custom reports
`SP`	A stored procedure	The procedure name	Data utilities, batch updates, nightly calculations
`EXE`	An external program	The program's name and path on the utility server	Integrations, file exports, anything outside SQL
`IDOMTH`	A method on an IDO	`IDO.Method`	Business logic that lives in an IDO rather than in SQL

A definition also has a task name (what appears in Active Background Tasks and History), a description, and buttons for report options and excluded tasks.

Finding what a report actually runs

Open the report form and note its background task name. It normally matches the form.
Open Background Task Definitions and filter on that task name.
Read the Executable Type and Executable Name.

For an RPT task, that gives you the report. From there you can find the data source behind it, usually a stored procedure, and test that directly in SQL Server Management Studio on a test database. This is the first step in almost every slow-report investigation. See Why your SyteLine report is slow.

Adding your own background task

To make a custom process run like a standard SyteLine task:

Build and test the executable on a test system first: the report, procedure, program or IDO method.
Create a record on Background Task Definitions with a clear task name, a description users will recognize, the right Executable Type, and the Executable Name.
Save it.
Call it from a form. Any form can submit the task through an event handler, so a custom form with a "Run" button can put the task in the queue for TaskMan to run.
Run it once in test and confirm the result in Background Task History.

Once it runs from a form, users can schedule it through the Background Queue like any other task. See How to schedule a SyteLine report or utility.

Making a custom program report its errors

When an EXE task fails, you want the reason to show up in Background Task History, not in a log file nobody reads. A program can report back three ways:

Return an integer exit code. TaskMan records it, and 0 means success. Anything else marks the task as failed.
Write an error message to a text file in TaskMan's Output folder, named after the task and task number (for example MyExport_435.txt). TaskMan uses it as the error message in history.
Write messages to the ProcessErrorLog table. They appear on the Task Messages tab of Background Task History.

Do at least the first two. An integration that "succeeds" with exit code 0 while silently skipping half its records is worse than one that fails loudly.

Good habits

Name tasks for humans. CustomOpenOrdersByBuyer beats Rpt47.
Prefix custom tasks (for example Cust or your company initials) so they're easy to separate from Infor's during upgrades.
Never repoint a standard Infor task at your own code. Create a new definition instead. Upgrades can reset standard records, and your change disappears.
Document each custom task, saying what it runs, who asked for it, and how to test it, in the same place as your other SyteLine changes.

FAQ

What is the Background Task Definitions form in SyteLine?

It's the list of every task the background queue can run, with the type and name of the executable TaskMan should call for each one.

What does IDOMTH mean in SyteLine?

It's the Executable Type for running an IDO method in the background, written as IDO.Method.

How does a SyteLine background program report failure?

By returning a non-zero exit code. It can also write a message to a text file in TaskMan's Output folder, or to the ProcessErrorLog table, so the reason appears in Background Task History.

Can I run my own stored procedure as a SyteLine background task?

Yes. Create a Background Task Definitions record with Executable Type SP and the procedure name, then call the task from a form.