Data In Action

Service components in this zone are tasked with acting on data that exists within the Data at Rest repository to implement federated workflow and other processing.

Web Services


Federated Workflow

Some Data in Action components expose a Web API so that they can be called by internal or external applications or services.

The Web API requires the InstanceGUID of the record that will be the target of the action.

The Web API also requires security tokens for each request to authenticate the requesting user.

Note that internal or external applications or services are never granted direct access to the Data at Rest components.

Typically, the larger Data in Action components are implemented as micro-services and may be constructed using many of the standard Domain Driven Design (DDD) techniques and technologies.

An interesting variant to standard DDD approaches is that the micro-services in the Data in Action zone use the Data at Rest services to persist data. This means that we do not persist any data locally in a Data in Action micro-service. This means that many of the issues normally associated with DDD micro-service architectures simply do not apply. Our Data in Action services don’t need to create deep call trees to access data provided by other services – they all have peer access to the same information via the Data at Rest service. This removes the need for data caching and eventual consistency solutions commonly found in traditional DDD solutions.

The Data in Action service approach leads to the creation of simple micro-services that focus on building a single (or small group of related) function(s). This significantly decreases service interdependencies, reducing the chances of cascading failure and performance bottlenecks - which improves solution resilience.

Database T-SQL


We don’t have to implement all Data in Action services as Web APIs.

We can also implement a Data in Action component as a T-SQL Stored Procedure within the database server that hosts the Data at Rest service. The T-SQL should also accept the same parameters as a Web API:

  • The InstanceGUID of the record that will be the target of the action.
  • Security tokens for each request to authenticate the requesting user.

The advantages of implementing the component inside the database include:

  • Raw performance.
  • We can use set based operations to process many records at once.
  • We don’t have to move data out of the database to process it and write it back when done.
  • We can take advantage of database transactions and exception handling mechanisms.
  • We can attach processing to database triggers to enforce business rules.

Other Data in Action implementations


We have considered Web APIs and T-SQL Stored Procedures separately as we frequently integrate these directly into the Data Presentation Model to enrich the user experience. We should also remember that Data in Action functionality can be delivered by ANY programmatic technology and some examples include:

  • Operating system services or processes.
  • Operating system command files
  • Compiled executables that sit on the operating system.
  • Serverless computing delivered through the cloud (e.g. Azure Functions).
  • Workflow solutions like Azure Logic Apps, Power Apps and Biztalk.

Over the last couple of years hybrid-cloud technologies have eroded the traditional deployment models. In the past, we would have deployed such services onto servers in well-defined network zones. Whilst there is still some server based deployment we are increasingly seeing Data in Action components being deployed using SaaS and serverless compute.

Invoking Data in Action services


Data Presentation Model – User Experience

One source of triggers for Data in Action services come from the interaction of a person with the user experience rendered on some platform (web, mobile app, etc.). We have already discussed the Data Presentation Model in detail, but it is worth recapping the trigger sources within the user experience:

  • Direct invocation using a Field Definition interaction (Button, Command etc.)
  • Indirect invocation because of a State Transition (Before or After state change)
  • Indirect invocation by tagging a Data in Action call on Concepts for:
    • When a record is saved
    • When a record is deleted

Pre-Scheduled and Ad-hoc Triggers

  • T-SQL Stored Procedures
  • Operating System Command Files and Executable
  • Automated Workflow

Polling Mechanisms

  • Operating System Service and Processes

Sustainability


The ability to add Data in Action components as micro-services using a hub and spoke model over the Data at Rest service enables us to take maximum advantage of both Domain Driven Design and the latest DevOps techniques.

Each Data in Action micro-service can be independently versioned, deployed and scaled.

It is also easy to onboard a new resource – they don’t have to understand how all possible services work – they simply focus on the functionality they are developing.

What is Data as a Service?

Data
at Rest

At rest within a persistent data storage medium

Data
Presentation

Presented as part of an omni-channel user experience

Data
in Action

In action when we want to perform some business logic on it

Data
in Motion

When being shared with third parties or other internal solutions