Real-Time Workflow
=============================================================================

At this time, the |prt| is the most common way to interact with providers that expose the information through an API or through their website. The workflow is described as **real-time** because every time a booking is traced, the results of its status are provided immediately. Of course, the time to trace the booking will depend on the provider implementation and the number of bookings. APIs are usually very fast where scrapes take longer to retrieve results.


The process is initiated by the client application by sending a **Booking Publish Request** to |encd|. |encd| notifies |enbtm| of the new event. |enbtm| generates a trace job for the booking and sends the job to |entbe|, which evaluates the job and sends it to the right provider implementation.

When the status is retrieved from the provider, |entbe| sends the results to |enbtm|, which generates the **Booking Result Response** and sends it to |encd|. |encd| receives the results response and notifies the client application through the exposed **Web-Hook**.

This initial trace of the booking may take just a few seconds or less depending on the interaction with the provider source of information; therefore, the name of |prt|.

Once the booking has been published by the client application the first time, |enbtm| will trace the booking again through the **Real-Time Scheduler** process that will initiate the trace. How frequently a booking is traced depends on several factors calculated from the status of the booking when the results are retrieved.

The goal is to provide information about status changes as frequently as possible while balancing the cost of querying the information.

The following sections document all the **Real-Time** providers supported and detailed information about how they work.


..  toctree::
    :maxdepth: 1
    :caption: Contents:

    rt/apm
    rt/ictsi
    rt/lbct
    rt/port-of-houston