Shop floor control workflow fails to advance on operator signoff

When operators complete their tasks and sign off, the shop floor control workflow fails to advance to the next operation. The signoff is recorded in the system, but the workflow remains stuck at the current step. I’ve reviewed the event handler mapping and the operator signoff event appears to be configured correctly. However, the workflow definition doesn’t seem to be processing the signoff event. Here’s the error from the workflow logs:


ERROR: Workflow transition failed for job J-5678
CAUSE: Event handler returned null response
at WorkflowEngine.processEvent(WorkflowEngine.java:245)

This is blocking job completion across multiple work centers and we’re falling behind schedule. Has anyone dealt with workflow advancement issues related to operator signoff in HM 2022.2?

I’ll provide the complete solution covering all three critical areas you need to address.

Event Handler Mapping Update: First, let’s fix the event handler configuration. Open your shop floor control workflow configuration file (typically config/workflows/shop_floor_control.xml). Locate the operator signoff event handler section. In HM 2022.2, the mapping structure changed significantly:

Old format (pre-2022.2):

<event-handler>
  <event-type>OperatorSignoff</event-type>
  <handler-class>OperatorSignoffHandler</handler-class>
</event-handler>

New format (2022.2+):

<event-handler>
  <event-type>OperatorSignoff</event-type>
  <handler-class>com.honeywell.mes.shopfloor.OperatorSignoffHandler</handler-class>
  <response-mapping>
    <response-code>SIGNOFF_COMPLETE</response-code>
    <workflow-action>ADVANCE_TO_NEXT_OPERATION</workflow-action>
  </response-mapping>
  <response-mapping>
    <response-code>SIGNOFF_REJECTED</response-code>
    <workflow-action>RETURN_TO_OPERATOR</workflow-action>
  </response-mapping>
</event-handler>

The response-mapping elements are critical. They tell the workflow engine what action to take based on the event handler’s response. Without these mappings, even a successful event handler execution results in null workflow action, which is exactly the error you’re seeing.

Operator Signoff Event Handler Code Update: Your custom OperatorSignoffHandler needs to be updated for the new API. Here’s the structure it needs to follow:

public class OperatorSignoffHandler extends BaseEventHandler {
  @Override
  public EventResponse processEvent(OperatorSignoffEvent event) {
    // Your validation logic here
    if (validateSignoff(event)) {
      return EventResponse.success("SIGNOFF_COMPLETE");
    } else {
      return EventResponse.failure("SIGNOFF_REJECTED", "Validation failed");
    }
  }
}

Key changes from the old API:

  1. Method returns EventResponse instead of void
  2. Response must include a response code that matches the workflow definition
  3. Use EventResponse.success() or EventResponse.failure() factory methods
  4. Response code must match exactly what’s in the response-mapping configuration

Recompile your custom handler with these changes and redeploy it to the server.

Workflow Definition Review: Finally, review your workflow definition to ensure the signoff step is properly configured. The workflow step definition should look like this:

<workflow-step id="operation_execution" name="Execute Operation">
  <completion-criteria>
    <event-trigger>OperatorSignoff</event-trigger>
    <required-status>COMPLETE</required-status>
  </completion-criteria>
  <on-completion>
    <action type="ADVANCE">
      <target-step>next_operation</target-step>
      <condition>event.responseCode == 'SIGNOFF_COMPLETE'</condition>
    </action>
    <action type="RETURN">
      <target-step>operation_execution</target-step>
      <condition>event.responseCode == 'SIGNOFF_REJECTED'</condition>
    </action>
  </on-completion>
</workflow-step>

The on-completion section defines what happens after the event handler processes the signoff. The condition must reference the response code returned by your event handler. This creates the complete chain: operator signs off → event handler validates → returns response code → workflow definition maps response code to action → workflow advances.

After making all three changes:

  1. Redeploy the updated custom event handler JAR file
  2. Update the workflow definition XML file
  3. Reload the workflow configuration (Admin Console > Workflows > Reload Configuration)
  4. Restart the workflow engine service
  5. Test with a single operator signoff
  6. Monitor the workflow logs to verify the event handler returns a valid response
  7. Confirm the workflow advances to the next operation

If you still see null response errors after these changes, enable debug logging for the event handler:


com.honeywell.mes.shopfloor.OperatorSignoffHandler=DEBUG

This will show you exactly what the event handler is receiving and returning. The most common remaining issue is a mismatch between the response code your handler returns and what the workflow definition expects. They must match exactly, including case sensitivity.

Once all three areas are properly aligned, operator signoffs will advance the workflow correctly and your jobs will complete on schedule.

Good catch. I checked and there is a custom event handler deployed for operator signoff. It was implemented about a year ago to add some validation logic. The handler class is OperatorSignoffHandler and it extends the base EventHandler class. Could this be incompatible with HM 2022.2? We upgraded about two months ago.

Almost certainly. The EventHandler base class changed significantly in HM 2022.2. The method signature for processEvent() was updated to return EventResponse instead of void. If your custom handler is still using the old signature, it won’t compile properly and will return null at runtime. You need to update the handler code to implement the new interface. Check the API documentation for the new EventHandler interface and update your custom handler accordingly.