System Internals
=============================================================================

|entt| supports multiple providers of container status information. These providers expose the information in different ways. Some of them provide an API that allows us to retrieve the information. Others publish that information to their websites, and we have to scrape the information.

There are providers who expose completely different means to access the information. This requires the |entt| system to support many different workflows to retrieve the status of containers.

The system has been designed to support many different workflows that exist today, but it's flexible enough to support additional workflows in the future. This guide documents and explains how the different workflow work, so applications that integrate the system can understand what to expect.

The most common workflow at the moment is the |prt|. This workflow provides immediate result status every time a container is traced. The system queries the status of containers through the provider and provides those results as they are retrieved.

Some providers use a |ppr| where containers are published and results are provided when the status of containers has changed. This means the containers are published once to the provider system, and that system will provide the results when there are changes. The |entt| system is responsible for querying the provider for changes.

There are provider systems that require an order to be published to request container status. Then the results are provided at a later time. This type of workflow is called |prd|, and there is a gap of time between the request being send and the results being available. Every time a container needs to be traced, a request needs to be published to the provider system.

Finally, there are systems where we can publish the containers and then expose a **Web-Hook** to handle results when they happen. We call this workflow the |ppn|. As we receive changes through the **Web-Hook**, the results are sent to the |tms|.

The following sections document each of the workflows, as well as the providers that use them.

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

    providers/realtime
    providers/publish-retrieve
    providers/request-delayed
    providers/publish-notify