Service Development

To develop micro-services implementing your business process, you need to have a basic understanding of how your scripts are being used in the SupercondActor Business Platform.

Business Platform Services and Applications

Business Platform Application is a logical grouping of Services. All services in the Application share the same set of JavaScript files - bundles where you pack all libraries needed for service Jobs to run.

An Application is represented by one TypeScript project, creating one Code Package that can be deployed to the Service Fabric cluster.

One Service Fabric cluster can host as many Business Platform Applications as you need, don’t hesitate to add another Application if if it makes the business logic more understandable.

To create a service you need to provide a Service Job code - describing what will be done on every execution cycle.

  • For a Scheduled Service the Job is run when the schedule is up, for example, every 15 seconds or at 1:00 am every Saturday.

  • For an API Service the Job is run for every HTTP request and returns corresponding HTTP response.

  • Long-running Service runs the Job once at startup - the Job should not exit, should run, for example, in an infinite loop.

The Service Job itself is usually short, just several lines of code, calling service implementation functions packed into a script bundles provided as one or more big JavaScript files common for all services in this Business Platform Application.

Global Context Object

Your JavaScript (TypeScript) code might need access to the underlying Service Fabric infrastructure, for example, to write a log message or read configuration info, to call another business service or create a new Business Platform Application, etc.

For that purpose the Business Platform runtime provides Global Context Object: _SupercondActor. You can use this global object anywhere in your code.

See ‘Global Context Object’ description in this documentation.

Structuring your code

You put the bulk of your code into one or more JavaScript bundle files, and call that code from the Service Job code specified for a particular Service.

The TypeScript projects provided as examples in our GitHub repository compile all your TypeScript files into a single `bundle.js` file, and pack it together with configuration files into a Code Package `BusinessScriptBundle.zip` file, ready for deployment.

How exactly you write your code depends on the type of services you are building. But in any case, behind the scenes, you bundle JavaScript files will be included with the require('bundle.js'); statement, and you service Job script will be run in the context of async function.

Job execution context - async function

Your service Job is always executed in the context of an async function, which allows you to implement asynchronous JavaScript processing while avoiding “callback hell” - you can use await operator instead of callbacks.

You don’t have to do anything specific to async processing in your code, just use await if you want, or write more traditional code handling Promise callbacks if you prefer that way.

The *await* expression causes *async* function execution to pause until a *Promise* is resolved, that is fulfilled or rejected, and to resume execution of the *async* function after fulfillment. When resumed, the value of the *await* expression is that of the fulfilled *Promise*. See the *await* operator description here.

See the execution context explanation in the diagrams below.

Scheduled and Long-running Services

Business Platform Scheduled Code Hosting

API Services

Business Platform API Code Hosting