d365fo-batch-runbase

name	d365fo-batch-runbase
description	Use when user asks about D365FO batch jobs, RunBase, or SysOperation framework. "does a batch job already exist for vendor aging", "scaffold a SysOperation for invoice processing", "find batch jobs related to purchase order cleanup", "RunBase vs SysOperation when to use which", "generate a batch class for ledger closing", "what existing batch jobs post vendor invoices", "scaffold a RunBaseBatch for periodic inventory recalculation"
license	MIT
metadata	{"version":"1.0"}

D365FO Batch & Background Processing

Find existing batch jobs and scaffold new RunBase or SysOperation classes for background processing. Ensures new batch jobs reuse standard D365FO scheduling infrastructure.

When to use

• User wants to check if an existing batch job covers a business requirement
• User is designing a periodic or schedulable process and needs to choose between RunBaseBatch and SysOperation frameworks
• User needs a code scaffold for a new batch class (DataContract + Service + Controller)
• User is writing a functional spec that includes a scheduled background process

Workflow

1. Search for existing batch jobs. Call find_batch_jobs(query) with business keywords (e.g. "vendor aging", "inventory close", "purchase order"). Prevents duplicating a class that already exists.

2. Recommend the right framework.

   Scenario	Framework	Reason
   Simple periodic process, dialog params	RunBaseBatch	Lighter weight, dialog built-in
   Complex multi-step, service-oriented	SysOperation	DataContract, Service, Controller separation; better testability
   Called from a menu item with parameters	SysOperation	Standard for new development
   Legacy class extension (CoC)	Stay on RunBaseBatch	Avoid mixing frameworks

3. Scaffold RunBaseBatch. Call generate_runbase(name) — returns XML for a class that extends RunBaseBatch with run(), dialog(), and pack()/unpack() already stubbed.

4. Scaffold SysOperation. Call generate_sysoperation(name, executionMode) — returns XML for the DataContract, Service, and Controller triplet with executionMode set to Synchronous, Asynchronous, or ReliableAsynchronous.

5. Document for the SFD. Describe the process name, trigger (menu item vs. scheduled), execution mode, key parameters, and which tables it reads/writes.

Output Format

Existing batch jobs matching query

Class name	Description	Module	Scheduler
VendAgingReportDP	Vendor aging data provider	Accounts payable	On-demand
InventClosing	Inventory close and recalculation	Inventory management	Periodic

SysOperation scaffold summary

Three files generated by generate_sysoperation:

File	Class role	Key members
<Name>Contract.xml	DataContract	[DataContract] [DataMember] parameters
<Name>Service.xml	Service	process(contract) — business logic here
<Name>Controller.xml	Controller	extends SysOperationServiceController

SFD process specification block

Process      : <Name>
Framework    : SysOperation / RunBaseBatch
Trigger      : Menu item <MenuItemName> / Batch schedule
Execution    : Asynchronous / ReliableAsynchronous
Parameters   : [list from DataContract]
Reads        : [table list]
Writes       : [table list]
Error policy : [retry / alert / skip]

Notes

• ReliableAsynchronous execution mode persists the DataContract to the database — use this for long-running processes that must survive an AOS restart.
• Always implement SysIRunnable checks if the batch class reads a large table — add a QueryRun with a proper range to avoid full-table scans.
• For processes that must run in a specific company context, extend SysOperationServiceController and override getCompany().
• Batch framework slots (threads) are a shared resource — document expected runtime and concurrency in the SFD.