Enterprise Batch Queue Management

Sepasoft MES Module Suite

Enterprise Batch Queue Management

• Centralized Batch Operations and Data Consistency
• Core Batch Operations from the Enterprise Level
• Batch Creation
• Checking Batch Status
• Removing a Batch
• Important Considerations and System Limitations
• Command Execution Restrictions
• Understanding and Mitigating Race Conditions
• Example Scenario: Updating an Order from ERP

Centralized Batch Operations and Data Consistency

Version specific: 3.81.11 SP9 and later

You can perform batch operations (addEntry, getStatus, removeEntry) from the enterprise root level. These commands are automatically routed to the correct site-level gateway, enabling centralized management across a multi-system network. The strategic importance of this architecture lies in enabling consistent business logic application, simplified auditing, and reducing the risk of data fragmentation common in decentralized models.

system.mes.batch.queue.addEntry()
system.mes.batch.queue.getStatus()
system.mes.batch.queue.removeEntry()

A fundamental design choice in this system architecture involves a tradeoff between system correctness and system availability. The functionality described here explicitly prioritizes data correctness. This means that batch operations are designed to ensure data is always current and accurate. Consequently, if the gateway network is down, these functions will fail until connectivity is restored. This behavior prevents data discrepancies and guarantees that all operations are based on the most up-to-date information.

The following sections detail the specific functions available for managing site-level batches from the enterprise.

Core Batch Operations from the Enterprise Level

Three core operations are available for managing site-level batches from the enterprise level: addEntry, getStatus, and removeEntry. This section details the specific functionality, parameters, and conditional behaviors of each command, providing a clear framework for remote batch management.

Batch Creation

The primary function of .addEntry is to create a Batch Queue Entry for a Site child, executed from the Enterprise level. The behavior of this function is conditional upon whether the processCellPath parameter is provided.

• When processCellPath IS provided:

  • The Batch Queue Entry is created directly on the target Site and subsequently synchronized up to the Enterprise. This behavior is consistent regardless of whether the Enterprise has its own Process Cell.

• When processCellPath IS NOT provided: The system's behavior depends on the Enterprise configuration:

  • Scenario 1: If the Enterprise has its own Process Cell, the system assumes the Enterprise can execute the batch. The entry is created at the Enterprise level and will not sync down to a Site.

  • Scenario 2: If the Enterprise does not have its own Process Cell, the Batch Queue Entry will automatically sync down to the Site that is capable of executing it.

This conditional logic ensures that batch entries are always homed on a system with execution capability, whether that is the Enterprise or a designated Site, thus preventing orphaned or un-executable batch jobs.

Checking Batch Status

The .getStatus function is used to retrieve the current status of a Site-level batch by calling the function from the Enterprise parent. This function's operation is independent of whether the Enterprise has its own Process Cell configuration.

Removing a Batch

The .removeEntry function is the sole approved method for retracting a batch job from the queue, ensuring a clean and auditable removal process from the enterprise level. It requires a batchQueueObject to be passed as an argument to identify the target entry, e.g., system.mes.batch.queue.removeEntry(batchQueueObject). This function's operation is independent of whether the Enterprise has its own Process Cell configuration.

These functions constitute the complete toolset for remote batch management. Effective implementation requires strict adherence to the operational constraints detailed next.

Important Considerations and System Limitations

While the core functions for batch management are straightforward, their application in a distributed system requires a clear understanding of key limitations. This section covers critical information regarding command execution permissions, potential race conditions, and the proper procedure for resetting a batch.

Command Execution Restrictions

An absolute rule governs command execution to maintain system integrity: The Enterprise is explicitly forbidden from executing commands on a Site child Batch, regardless if the Enterprise has its own Process Cell or not.

To "reset" a batch, users must call the .removeEntry function. Attempting to execute other commands from the Enterprise to modify a batch's state will fail.

Understanding and Mitigating Race Conditions

A potential race condition can occur during a multi-step batch update process. If a user fetches batch information, modifies it locally, then deletes the old batch to add the new one, another user could modify the batch on the remote system between the read and delete operations.

This is not a concern under the following conditions:

• The new batch being created is not based on the data from the old one.

• The system enforces a policy where batches are immutable and are never written to after their initial creation.

3.2. Adherence to these constraints is crucial for building robust and predictable workflows, as demonstrated in the practical example that follows.

Example Scenario: Updating an Order from ERP

A common business scenario involves updating production information based on changes originating in an external system, such as an Enterprise Resource Planning (ERP) system. This example demonstrates how to use the full suite of batch operations to handle a change to an existing order.

This multi-step workflow directly enforces the system's core principle of prioritizing data correctness. A direct "update" command is not provided, as this deliberate, conditional process of checking, removing, and recreating is essential for guaranteeing data integrity in a distributed system.

1. Receive Change Notification The Enterprise receives a notification from the ERP system indicating that an existing order has been modified.

2. Verify Batch Status Before taking any action, the user checks if the corresponding production batch has already started by calling system.mes.batch.queue.getStatus from the Enterprise.

3. Remove Existing Batch (If Inactive) If the status check confirms the batch has not started, the user deletes the existing, outdated batch by calling system.mes.batch.queue.removeEntry.

4. Create New Batch with Updated Data Finally, the user creates a new batch with the updated information from the ERP by calling system.mes.batch.queue.addEntry.

This workflow leverages the full suite of Enterprise-level batch operations to ensure data consistency in response to external system updates.

Sepasoft MES Module Suite