Skip to main content

Data Flows

Different data processing flows are possible with priint cloud rendering.

We recommend the Asynchronous flow with upload and/or callback flow.

The sequence graphs below are intended to give an overview but not to be complete.

  • only successful renderings are shown
  • integration of error and transform components is not shown
  • time lags between components due to decoupled processing are not indicated

Components​

Components on the customer side

  • Customer HTTP client is initiating the whole process via calls to the priint REST API.
  • Customer HTTP service implements webhook endpoints for upload, callback and error services of priint. This is to receive the PDF results.

Components the customer calls

  • Auth API is a simple OAuth2 interface to retrieve tokens for REST API authorization.
  • Render API implements some endpoint for starting rendering jobs and retrieving the status and result ob such jobs.

Backend components doing the job and storing the artifacts

  • RenderPdf acts mainly as a service to create PDFs from data and comet_xml projects.
  • Upload acts mainly as an HTTP client to send PDFs to a webhook endpoint of the Customer HTTP service.
  • Callback acts mainly as an HTTP client to send simple success notification payloads to a webhook endpoint of the Customer HTTP service.
  • Error acts mainly as an HTTP client to send simple error notification payloads to a webhook endpoint of the Customer HTTP service.

Optional components not shown below

  • Transform acts as a service to transform incoming customer XML or JSON into XML that is compatible with comet_xml.

Asynchronous flow with upload and/or callback​

As variant of this flow either upload or callback can be undefined and thus stepped over.

Error messages are placed into the queue by failures in renderpdf, upload or callback service. Error service itself works exactly like the callback service except for the content of the payload.

Asynchronous flow with polling​

caution

Not recommended. This is not recommended since polling is not an efficient process.

The use case of this flow is during development of a project when the webhook endpoints are not yet implemented and online.

Synchronous flow​

caution

Not recommended. Synchronous renderings will be inefficient and slow.

Synchronous renderings will be handled with low priority in the system. Their use case are test renderings and alike.