Execute Architecture

Overview of the Execute Architecture.

Execute is roughly split into a three components:

  • Database Server – Relational database which persists AFE information, audit information, business rules, configuration data, and lookup tables.
  • Execute Service – Windows service that interacts with the database, hosts the web pages that make up the client user interface, hosts the Execute APIs, executes scheduled jobs and coordinates integrations.
  • Client – The presentation layer. Either web-based or Windows Desktop based. The presentation layer is a thin wrapper around the APIs presented by the Execute Service.

Click image to expand or minimize.

Database

Execute supports both Oracle and SQL Server. The Execute Service connects to the Execute database and handles basic IO operations (loading, saving, search, reporting, etc). 3rd party tools can integrate with the database through staging tables (for inbound data) and reporting views (for reading data).

Application Server

The Application Server is the primary component for Execute.

The Application Server is a standalone Windows Service written in C#.

The Application Server performs a number of tasks, including:

  • Interfacing with the database and performing IO operations
  • Implementing all business logic and enforcing business rules and workflows
  • Serving the APIs which are used by the web-base interface, Windows desktop client, and 3rd party tools to interact with AFEs
    • The APIs used by the Execute User Interface are documented and available for use by 3rd party tools.
  • For performance reasons much of the AFE data is cached in memory. The service handles loading and maintaining this cache.
  • Managing and executing scheduled jobs such as email reminders, maintenance tasks, inbound data synchronizations, etc.

Clients

Most users will access Execute through the web-based interface. These are static HTML and Javascript pages that are served by the Execute Service and which directly interact with the Execute Service through the Execute APIs (rather than server side technologies such as ASP.NET). This lightens the load on the server and allows for efficient handling of large numbers of users.

The web-based interface supports all modern HTML5 compliant browsers including IE9+, Firefox, Chrome and most current mobile browsers (iOS, Android and BlackBerry). The web-based interface is common among all client devices and designed to be responsive so that it scales to take advantage of each device’s form factor. This means users have a familiar experience regardless of the device they are using.

Some administrative tasks are managed through the Execute Windows Desktop application. This application also connects to the Execute Service and uses the Execute APIs to interact with the system. In addition, some reports are run through this tool and, consequently, it connects directly to the database for fast reporting. The Windows Desktop interface is commonly deployed via Citrix/Terminal Service to enable remote administration.

External Systems

Execute supports integration with 3rd party systems through a number of mechanism:

  1. 3rd party systems can call into Execute through the Execute APIs. These systems are able to query for AFEs, read AFE data, change AFE data, and perform administrative options. The APIs enforce the privileges granted to the connecting user. This interface is commonly used by 3rd party systems to automatically create AFEs upon an event in an external system.
  2. 3rd party systems wishing to push data into Execute such as lookup tables (list of vendors, GL accounts, users, etc) or AFE master data (well information) can do so through staging tables. Execute is then configured to process the data in the staging table and sync it into Execute when appropriate.
  3. Execute can present the user with live pick-lists from 3rd party systems. This is often used during AFE creation to pick and copy data from an existing system rather than requiring duplicate entry.
  4. Execute has specific mechanisms for importing costs (both actual costs and field costs) from Accounting and Well Management software. These can be scheduled to run automatically.
  5. 3rd party systems wishing to extract data from Execute in bulk can do so through reporting views in the Execute database. These views abstract those systems from changes in the Execute schema.
  6. Execute can notify 3rd party systems of life-cycle events to the AFE (such as an AFE being sent for approval, approved, rejected, closed, etc) in real-time through Enterprise Events. The delivery can take place over SOAP, XML over HTTP, Queue (ie. MSMQ), calling out to an external EXE, or through a stored procedure. This mechanism is commonly used for pushing an approved AFE into SAP.
  7. Execute can request a 3rd party system perform validation of AFE data in real-time through Enterprise Validation. Enterprise Validation sends the AFE data to the 3rd party system via SOAP or XML over HTTP and that system responds with a list of validation warnings and errors that are presented to the user taking the action which caused the validation. This mechanism is commonly used for verifying AFE information against SAP prior to approval to ensure that, once approved, the AFE will integrate cleanly.