# Production API
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.
# Production Path
The basis of the Production Path modelling is that
MaterialRequirements are turned
Worksteps. These can be linked together to ultimately
result in the
This can be simplified into a recursive pattern, where
IntermediateProducts are consumed by
IntermediateProducts are emitted.
Assembling a Production Path is simple. Each
IntermediateProduct is linked to two
Workstepthat results in it being created, or transformed from another state into this state
Workstepthat utilises this
IntermediateProductas the next link on the Production Path
The end of the chain is represented by a
FinishedProduct, representing the final state
Job after all
Worksteps have been completed.
# Intermediate Products
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:
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
dependent on where in the chain it lies.
Details of the layout schema can be found here.
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:
- 100 Worksteps, one for each signature
- 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
Worksteps are automatically part of a
WorkstepGroup, even if they are only single items.
WorkstepGroup can either be explicitly created through the API, and then
to it as they are created, or one will implicitly be created when a
Workstep is added.
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
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
Worksteps are contained within a
WorkstepGroup is arbitrary and left to the developer's
discretion and knowledge of the use-cases.
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)
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
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.