Routing Order Process Flows

Routing a transaction is a central function within a Platform 6 document flow. It involves sending a message to a Routes Service (Apache Camel) endpoint and depending upon the message and endpoint configuration, a variety of often complex queued asynchronous or synchronous operations are initiated.

This diagram attempts to detail and explain many of the options available to a Platform 6 developer and highlight the different behaviours that result from their choices.

Warning

Building the correct ARO (Active Routing Order) behaviour to match the workloads required of Platform 6 is essential. Platform 6 is not an infinite bucket in which transactions can be poured! Transaction flow into and through Platform 6 needs to be designed to suit the business needs and volumes required of customer projects.

Platform 6 implements a message driven architecture. Messages are exchanged between Platform 6 services and Apache Camel (Camel Exchange Messages) and between Platform 6 services themselves (Platform 6 Common Message).

Messages are queued and are often processed by pools of worker threads. Queues and thread pools all have fixed sizes (many configurable on a per-instance basis). When all threads in a pool are in use, messages are queued. If the number of messages in a queue exceeds the maximum configured size, the message is rejected and an error occurs.

When designing a Platform 6 flow it is important to model the messaging behaviour and the resulting use of pooled threads. For example, if a file contains 1000 invoices and each invoice causes the execution of a single script, 1000 scripts must be run. With a pool of only 32 script running threads available, 968 execution request messages will be immediately queued. Depending upon how long each invoice script takes to run, processing the backlog of queued requests may take quite some time and more importantly, any other flow that requires script execution will also be blocked/queued until the backlog is processed.