You're the BOSS: Getting to know SAS Business Orchestration Services

In this first of several articles about BOSS, you'll learn all about SAS Business Orchestration Service, from the history of BOSS to how it supports various SAS Solutions. We'll learn how BOSS projects are created, structured, and deployed.

We'll discuss BOSS using SAS Fraud Decisioning as our primary example, but BOSS is also an important part of several other SAS Solutions including SAS Fraud Management and SAS Real-Time Watchlist Screening.

World-class software and analytics are only as useful as the data they are able to access and use. Often this data is in an improper format for a particular software solution, and/or is in several different locations. For SAS solutions like Fraud Decisioning to function, data must be orchestrated between client systems, SAS solutions, and 3rd party systems.

BOSS orchestrates that data, connecting and coordinating different data sources and transforming, enriching, and validating the data as needed.

What's BOSS?

BOSS is a configuration-based data orchestration engine that connects loosely coupled systems. BOSS can ingest data from multiple sources, process it, and output to multiple destinations.

BOSS connects the other components of SAS Solutions like SAS Fraud Decisioning with each other, as well as with client and 3rd party systems. Let's consider an example where a bank's systems sends transaction information to BOSS. BOSS add fields and formatting required by SAS Fraud Decisioning before passing the message on to the runtime environment.

BOSS can also be used to incorporate external data into transactions or alert pages, validate transaction metadata or content, and to enrich transactions with data from other sources. BOSS is extremely adaptable, so you can add it into your environment and configure it for whatever you need it to do. This means there are many possible use cases for BOSS depending on the organization's needs. We'll take a closer look at some of those use cases for BOSS in Part 2.

The first iteration of Business Orchestration Services was part of SAS Fraud Management. It was on-premises and highly complex. What is now referred to as 'Classic BOSS' utilized multiple languages and required skill with Apache Camel, Java, and Groovy.

In classic BOSS the workers were also managed independently of each other. Though it was highly configurable, the multiple dependencies limited debugging, and updates and dependencies were problematic when maintaining environment stability. You can learn more about Classic Boss in its own User's Guide: Classic SAS Business Orchestration Services User's Guide.

Today's Business Orchestration Services is cloud-native and serves a similar role for SAS Fraud Decisioning, but with a few important key differences. Now, BOSS is streamlined and has a simplified but highly expressive language. It is built using Golang and has reduced dependencies compared to classic BOSS, making configurations more robust.

BOSS workers are now managed as part of a unified configuration instead of separately. The low-code user interface facilitates easier creation and deployment of BOSS projects (more on that in a moment). Logging is built in and debugging is much easier.

Navigating Business Orchestration Services

I can define, test, and deploy data flows in the BOSS user interface. The user interface is available as of the 2025.04 release, with added functionality in subsequent releases.

From the SAS Applications menu, I can find BOSS under the Administration heading. I'll select Business Orchestration Services.

To access this interface, I need to be in one of the Business Orchestration Services predefined custom groups.

These 4 groups have the required privileges to view the user interface, and depending on the role, have different other abilities.

Let's explore the Business Orchestration Services user interface, starting with the homepage. I can quickly start a new project from this page, or view recent projects in a tile or list view. I could click a project under Recent Work to open it from the homepage if desired.

Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.

I'll continue to the Projects tab. This tab lists all projects. I can view current or archived projects, and see the validation status. I can open projects from this tab, as well as deploy or archive them.

From left to right on the Projects page: Create a new project, archive a project,

deploy a project, delete a project, refresh project list.

Next, I select Deployments. This tab lists the deployments along with the health of each. The environment and number of workloads in each deployment is also listed. I could redeploy from this tab, or delete deployments.

Now let's return to the Projects tab and open one. I select SFD Workloads and open it.

When editing the project definition, you have the following controls: Left: undo, redo, cut, copy, paste, find and replace, clear all, print, editor settings.

Top right: Save, deploy, delete, close. Right Side: Properties

Now that I’ve opened the project, I can view and edit the project definition with the toolbar shown. The settings icon allows me to configure the code editor settings.

For example, you can disable the minimap shown on the right side of the screen near the scroll bar, change code suggestion options, and use different themes in the editor including dark mode.

I can save the project, and once it is saved, deploy it.

Anatomy of a BOSS Project

Now let's examine the project code itself. BOSS workers are organized in a hierarchy, starting with projects. The project is the configuration YAML file that the BOSS engine runs.

Projects have several required fields: ID, version, and workloads. The ID and version are a string, and the workloads object contains workloads - groups of flows that run in the same container. In addition to the required fields, a project can have a label and details. Let's look at the required and optional fields for this project.

The project file is shown including the id, version, label, details, and workloads fields. The workloads object has been collapsed to emphasize which variables are at the project level.

The id is sfdWorkloads. The version is v1. This project also has the optional label and details fields, giving us more information about what it contains.

We're currently viewing a project file that contains all the needed workloads to implement Fraud Decisioning. Workloads can be scaled independently from each other.

The only required field for a workload is the flows object, but you can also include a label and detail field, as well as workload-wide configurations. Let's look at the workloads in this project. I've used the arrows next to the line numbers to collapse the flows objects so it is easier to see the entire workloads.

There are two workloads. The first is labelled Real-Time Workloads, and the second is Batch Workloads. The configurations object includes workload-wide settings including the logger behavior.

Workloads contain flows: ordered, complete sets of actions that define the way data moves through BOSS. Flows orchestrate calls to endpoints and make the routes between them. There can be many flows in a single workload.

When defining a flow, you can optionally define a label and details. Other optional fields include input batching policies and output batching policies.

-label: ...
 details: ...
 inputsBatchingPolicy: ...
 inputs: ...
 processors: ...
 outputs: ...
 outputsBatchingPolicy: ...

Actions in flows are performed on messages as they pass through the flow, and there are three: input, processor, and output.

Intuitively, input is always first action in the flow. The input provides the data to pass through the flow, in a batch of one or more. Each flow must have at least one input.

Let's look at some examples of inputs. A file input reads data from a file on the disk, and places it into messages. An HTTP server input defines and endpoint that the client calls to receive the data for the flow.

httpServer:
    allowedVerbs:
        - POST
    details: custom input details.
    label: My custom label.
    path: /api/data
    syncResponse:
        headers:
            - key: Content-Type
              value: application/json
        metadataHeaders:
            includePrefixes: []
        status: "200"
    timeout: 5s

Each input type has its own required properties. In this case, allowedVerbs specifies the allowed HTTP methods for the path, while path provides the endpoint. See the Business Orchestration Services User Guide for a full list of currently available inputs and their required properties.

Processors are optional, and perform processing on the message. BOSS has special terminology to distinguish the input vs. the output of the processor. The this prefix indicates that a field is being referenced from the message entering the processor, and the root prefix indicates the value is to be outputted from the processor. Map is one of the most common processors, and can be used for data manipulation and enrichment. The results of the map processor replaces the original message.

map:
    details: custom processor details
    label: My custom label.
    mapping:  |
          root = this
          root.message.color = "Green"

In this example, the defined mapping first assigns the outputted value the same as the inputted value, then reassigns the outputted message variable 'color' to Green.

Other common processors include http and kafka, but there are dozens more with a wide variety of functions. For example, there are processors to convert between Ion, JSON, and XML formats. There are also several processors only for use with SAS Real-Time Watchlist Screening.

Outputs are required, and must be the final flow action. They send the data to a destination outside of the flow in a batch of one or more. HTTP client outputs can call an external endpoint with the results of the flow, or an HTTP server output defines an output endpoint for a client to call. The Kafka output writes messages to a kafka broker. You can also use the standard output.

kafka:
    addresses:
        - 192.168.1.1:9092
        - 192.168.1.2:9092
    batching:
        byteSize: 0
        count: 0
        period: ""
    details: My custom details.
    label: My custom label.
    metadataKeyPrefixes: []
    sasl:
        enabled: false
        mechanism: PLAIN
        password: ${PASSWORD}
        username: ${USER}
    tls:
        caFile: /path/to/ca-cert.pem
        certFile: /path/to/client-cert.pem
        enabled: false
        keyFile: /path/to/client-key.pem
    topic: test_topic
    transactionEnabled: false

With such a wide variety of actions to combine into flows, it's easy to understand how BOSS is so versatile and configurable. You can create BOSS projects for simple or complex data flows to meet your specific needs.

For more detailed information about actions and expression language and examples of projects, workloads, and flows, see the Business Orchestration Services User Guide.