Logo

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 Instance GUID 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, so 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 function, or small group of related functions. 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 accept the same parameters as a Web API:

  • The Instance GUID 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:

  • Improves raw performance
  • Uses set based operations to process many records at once
  • Don’t have to move data out of the database to process it and write it back when done
  • Takes advantage of database transactions and exception handling mechanisms
  • Attaches 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; 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 computing.

Invoking Data in Action services

Data Presentation Model – User Experience

One source of triggers for Data in Action services comes 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 are Data Agnostic Services?

Data
at Rest

within a persistent data storage medium

Data
Presentation

as part of an omni-channel user experience

Data
in Action

when we perform business logic on it

Data
in Motion

between data stores