Concept of Blueprint
Blueprint is a domain-specific programming language (Domain Specific Language) defined in YAML format for exaBase Studio.
It can be written in YAML format, which engineers are familiar with. Furthermore, it is possible to create Blueprints using the GUI feature called Canvas in Studio App, allowing non-engineers to use it and collaborate in team discussions to advance the design collectively.
Vision of Blueprint
In general, the demands on systems change in response to fluctuations in business operations and information processing. In particular, digital transformation (DX) often requires repeated trial and error to discover the ideal state, necessitating responses to various changes and modifications. Additionally, as business and technical issues and constraints influence each other, it is essential to facilitate smooth conversations among diverse stakeholders.
We emphasize the importance of the following aspects to achieve results in such uncertain environments:
- A common language that stakeholders can understand at a certain level in both business and technology
- The ease of quickly verifying whether the desired effect can be expected
- A flexible process that can promptly respond to requests for changes
Blueprint was born from this context.
Blueprint separates data representation from processing, making it easier to implement such changes.
Functioning of Blueprint
By deploying Blueprints, users can create executable programs running on servers called Circuits.
Circuit
A Circuit is an executable program constructed on the server based on the information described in the Blueprint. Imagine a circuit generated from a blueprint.
A Circuit is composed of Entities, Endpoints, Triggers, and Pipelines. Each of these components is launched as a Pod on Kubernetes, existing as independent services.
How to Use Blueprint
Blueprint allows the design of systems by combining components called nodes.
View sample code of Blueprint in YAML
constructorApiVersion: v1alpha60
metadata:
name: Your Test Blueprint!!
description: |-
A long description field to allow us to describe what is going on
with this wonderful test blueprint!!!!!
version: 0.0.1
labels:
env: production
debug: no
workspaces:
- id: workspace-test-accounting
metadata:
name: Test Workspace for Accounting
description: "This is the test workspace for accounting that we will be using to test sending and receiving data with triggers and pipelines"
version: 0.0.1
labels:
usesSAGE: No
integrations: "SAGE, Excel, GoogleSpreadsheet"
entities:
- id: e1
metadata:
name: Normal Entity
description: "This is a Normal entity"
type: io.ebstudio.core.entity.data
expires: 60000
interval: 1000
- id: e2
metadata:
name: Binary Entity
description: "Binary entity for use with files"
type: io.ebstudio.core.entity.file
endpoints:
- uri: /ep1
type: io.ebstudio.core.entity
target: e1
authorizedIps:
- 126.122.122.12/32
- 126.122.122.0/24
bind: ReadOnly
- uri: /ep1
type: io.ebstudio.core.sideapp
port: 8080
target: sideapp-service
bind: ReadOnly
- uri: /ep1
type: io.ebstudio.core.pipeline
target: pipeline-1
bind: ReadOnly
triggers:
- id: check-if-e1-or-e2-has-new-value
metadata:
name: New trigger Names
description: "Trigger using rxjs"
type: io.ebstudio.core.trigger.script.rxjs
entities:
- id: e1
default: "Test Value"
- id: e2
default: 23
script: |
'use strict'
const { getEntityAsObservable, disposeBag } = context;
getEntityAsObservable('e1')
.subscribe(x => {
// received data is converted to JSON value if available
if(Array.isArray(x)) {
console.log(`array: ${JSON.stringify(x)}`);
} else if(typeof x === 'object') {
console.log(`${typeof x}: ${JSON.stringify(x)}`);
} else {
console.log(`${typeof x}: ${x}`);
}
})
.putIn(disposeBag);
requirements:
- dayjs
- lodash
environment:
ENVNAMETEST: EnviromentTestVariable
ENVNAMETESTSECRET: ${{SECRET.EnviromentTestKey}}
storage:
- path: /tmp/asdasad
injection:
- path: /tmp/asdasad.py
data: |
asdasd
asdasdasd
asdasdas
pipeline: pipeline-test
pipelines:
- id: pipeline-test
name: One Pipeline Test
description: "A pipeline test"
type: io.ebstudio.core.pipeline.atpipeline
try:
steps:
- id: pipeline-test-step-1
description: "This is pipeline test step one"
computeType: CPU
image: test-test-test.dkr.ecr.ap-northeast-1.amazonaws.com/ebstudio/test-test:latest
environment:
ENVNAMETEST: EnviromentTestVariable
ENVNAMETESTSECRET: ${{SECRET.EnviromentTestKey}}
predefinedInputs:
- id: testPreDefinedInput
data: |
a test data string
inputs:
- type: entity
id: e1
data: /tmp/entity--e1.txt
outputs:
- type: entity
id: e3
data: /tmp/entity--e3.txt
- type: filesystem
id: e1-file-data
data: /app/test/e1-filedata.zip
- id: pipeline-test-step-2
description: "This is pipeline test step two"
computeType: GPU
image: test-test-test.dkr.ecr.ap-northeast-1.amazonaws.com/ebstudio/test-test:latest
inputs:
- type: filesystem
id: e1-file-data
data: /app/test/e1-filedata.zip
outputs:
- type: entity
id: e4
data: /tmp/entity--e4.txt
except:
steps:
- id: pipeline-test-step-2
description: "This is pipeline test step two"
computeType: GPU
image: test-test-test.dkr.ecr.ap-northeast-1.amazonaws.com/ebstudio/test-test:latest
inputs:
- type: exception
id: e1-file-data
data: /app/test/e1-filedata.zip
outputs:
- type: entity
id: e4
data: /tmp/entity--e4.txt
sideapps:
- id: test-sideapp
metadata:
name: Sideapp One
description: "A lovely sideapp"
type: io.ebstudio.core.sideapp.service
image: test-test-test.dkr.ecr.ap-northeast-1.amazonaws.com/ebstudio/test-test:latest
environment:
ENVNAMETEST: EnviromentTestVariable
ENVNAMETESTSECRET: ${{SECRET.EnviromentTestKey}}
storage:
- path: /tmp/asdasad
injection:
- path: /tmp/asdasad.py
data: |
asdasd
asdasdasd
asdasdas
Components of Blueprint
In Blueprint, the Entity and Trigger are used to represent the context of the real world in the information space. Resources such as Pipeline and Function are activated only when necessary, based on the expressed context, to perform information processing employing technologies like AI. Each node is constructed on a Circuit when Blueprint is deployed, operating as independent small services (Kubernetes Pods).
| Name | Function | Purpose |
|---|---|---|
 Trigger | Receives events from multiple independent sources and maintains decision states for pattern extraction incorporating time | Constantly monitors one or more Entities and only kicks off Pipelines when conditions described in reactive language are met. By combining Entity variables and Trigger descriptions, it enables the expression of complex real-world occurrences. |
 Entity | Maintains references to data or files | Variables that store values or files. They respond to input/output via endpoints and can provide reference information to the data exchanged inside and outside the Circuit, enabling event definition through Function input/output and Trigger monitoring. |
 Endpoint | Web interface bound to the Entity | Allows fetching or assigning the contents of entities from the outside |
 Pipeline | Listener for executing pipelines | Encompasses one or more Functions, allowing for sequential execution. |
 Function | Maintains execution states of functions | Functions running in a Pipeline. Contents are containerized and uploaded to external repositories, with URIs described in Blueprint. Each one cold starts after the completion of the previous process, enabling resource optimization. |
 SideApp | Runtime for custom containers | Can function as a web server that remains operational to facilitate the processing of Pipelines triggered under specific conditions. Access to resources on the Circuit is possible. |