Production API

• Introduction
• Concepts
  • Production Path
  • Intermediate Products
  • WorkstepGroups
  • Imposing
  • Delays

Introduction

The Production API represents the core concepts required to model the production of a Job.

Full details of the API endpoints and schemas can be found in our API documentation and support is available through our community Slack channel.

Concepts

Production Path

The basis of the Production Path modelling is that MaterialRequirements are turned into IntermediateProducts through Worksteps. These can be linked together to ultimately result in the FinishedProduct.

This can be simplified into a recursive pattern, where MaterialRequirements and IntermediateProducts are consumed by Worksteps, and IntermediateProducts are emitted.

Assembling a Production Path is simple. Each IntermediateProduct is linked to two Worksteps:

• a creating_workstep - the Workstep that results in it being created, or transformed from another state into this state
• a consuming_workstep - the Workstep that utilises this IntermediateProduct as the next link on the Production Path

The end of the chain is represented by a FinishedProduct, representing the final state of a Job after all Worksteps have been completed.

Intermediate Products

An IntermediateProduct is a by-product of a Workstep. They offer an advanced representative model, allowing for full, syntactically accurate transfer of layout information through the entire Production Path - a property we would strongly advise making the most of.

This can be visualised as follows:

Each IntermediateProduct has a full layout property that should be populated with details representing the assembly of that segment of the Job at that point in the Production Path. These could be derived from either a previous IntermediateProduct's layout, or from the initial Part dependent on where in the chain it lies.

Details of the layout schema can be found here.

WorkstepGroups

Data Platform supports extremely granular modelling of Production Paths. Our MIS platform, Keyline (opens new window), approaches Production Path modelling in a simple manner - for each Part there would be a single Printing task to complete. Unfortunately, this leads to complexities in doing processes such as batch or gang printing.

The Data Platform model solves this. We would urge all connected applications to represent Production Paths in the most granular way possible. A Part with 100 signatures to print should result in one of:

1. 100 Worksteps, one for each signature
2. N Worksteps, one for each batched sheet where signatures have been combined for printing

This, however gets more difficult to keep track of - for example, calculating progress becomes more difficult. To offset this, we have the concept of a WorkstepGroup.

All Worksteps are automatically part of a WorkstepGroup, even if they are only single items. A WorkstepGroup can either be explicitly created through the API, and then Worksteps allocated to it as they are created, or one will implicitly be created when a Workstep is added.

The WorkstepGroup allows for simple progress reporting, and can be used as a proxy for a simpler model - progress can be reported through the WorkstepGroup if desired, and we will heuristically attach it relative to the constituent members of the group.

This does also allow huge flexibility in how things are combined. Given the above basic setup, where a printing Workstep exists for each Signature within a Part, there are at least two options for how subsequent Worksteps could be managed.

Granular Approach

This approach keeps all future operations entirely separate, allowing for full control and independent monitoring.

Simplified Approach

This approach allows granular reporting of each Workstep in the WorkstepGroups if desired but also to have a simple overview of how much folding or how much printing needs to be performed.

Which Worksteps are contained within a WorkstepGroup is arbitrary and left to the developer's discretion and knowledge of the use-cases.

Imposing

Data Platform does not do Imposing, and does not offer an Imposing engine. It does, however offer a detailed data model describing Imposing, based on our layout engine.

The API details are available here (opens new window)

Delays

Unfortunately, sometimes stuff goes wrong. Despite the best planning and maintenance, materials are not delivered on time or machines require attention. To encapsulate what happened and provide traceability and information to scheduling teams, creation of JobDelay objects is advised whenever an exception occurs in production.

These can be created using a simple API call (opens new window) and have a reason and description available to pass semantically meaningful information on to teams monitoring production.

Once the exception conditions have been resolved, the JobDelay can be cleared - indicating that production can resume.