OpenRules business decision models can be deployed as operational decision services utilizing the Serverless architecture provided by AWS.  Deploying your decision models as AWS Lambda functions you don’t even think about servers and pay only for the execution time your services actually consume.

However, the cold reality is that AWS is complicated, and the way how you build and deploy your AWS Lambda Decision Service is usually not straightforward. It may require deep understanding of the AWS environment and essential coding and configuration efforts. OpenRules Decision Manager dramatically simplifies this process by automatically generating all necessary components and allowing you to convert your business decision model to AWS Lambda function without any coding. They can do it even directly from their local installation by one click on the provided batch file “deployLambda.bat“!

Sample Project. The standard sample project “VacationDaysLambda” demonstrates how to deploy your business decision model as an AWS Lambda function. It deploys the already created and tested decision model  in the sample project “VacationDays”. It uses the same rules repository “VacationDays/rules” and the adjusted file “project.properties”. It includes two new files “deployLambda.bat” and “undeployLambda.bat”. When you double-click on “deployLambda.bat” it will automatically create the AWS Lambda function “VacationDays”.

Setting AWS Lambda Deployment Properties. We assume that you already have an active AWS account and created your security credentials (access key ID and secret access key) which should not be shared with anybody. Then you should define your AWS Lambda deployment properties in the provided file “project.properties“. Here is an example of the required settings:

aws.lambda=On
aws.lambda.bucket=openrules-demo-lambda-bucket (your own unique S3 bucket!)
aws.lambda.region=us-east-1                                                         

The property “aws.lambda.bucket” defines any new or existing S3 bucket name, e.g. “your-company-lambda-bucket”.

Optionally, you may use additional settings to specify more details about your AWS deployment preferences. For example, by default we use the word “test” (inside the invoke URL) as your deployment stage. But you may redefine it as “dev”, “prod”, or any similar word using this setting:

aws.api.stage=test

By default your deployed service will be publicly accessible, but it is possible to make it private.

Usually people keep their AWS Credentials (access key ID and secret access key) in the default file ~/.aws/credentials. However, alternatively you may define them directly in the file “project.properties”:

aws.access.key.id=<aws-access-key-id>
aws.secret.access.key=<aws-secret-access-key>

One-Click Deployment. When you simply click on the standard file “deployLambda.bat“, the decision model will be deployed and the console log will show the invoke URL for the deployed decision service (highlighted in the following example):

Testing Your Lambda Decision Service. To test your deployed decision service,  during “deployLambda.bat” OpenRules generated the file “testLambda.bat” that already includes the above invoke URL. When you click on this file, it remotely executes all test cases defined in the Excel file “Test.xls” against just deployed AWS Lambda. When you run “testLambda.bat” for the first time, it will show the testing results as follows:

 

 

 

 

 

 

 

 

 

 

 

 

                                                            AWS Lambda “Cold Start”

Please note that that start time for this Lambda function took almost 2.5 seconds (2437 milliseconds) while all tests where executed very quickly within only 4 milliseconds. The “slow” start was caused by the so-called Lambda’s “Cold Start” when a new instance handles its first request. Cold starts happen 10 minutes after the previous request.

If you repeat “testLambda.bat”, you will receive the following results:

 

 

 

 

 

 

 

 

 

 

 

                                                              AWS Lambda “Hot Start”

Note that the start time went down from 2437 to only 87 milliseconds – this effect is known as Lambda’s “Hot Start” and should be taken into consideration when you select your deployment options.

Testing with POSTMAN. You may test this decision service with the popular graphical tool POSTMAN by proving the Lambda’s URL and entering test data like in this view:

Invoking AWS Lambda from Java. The example “VacationDaysLambda” includes the Java class “LaunchClient” (in the folder “src”) that demonstrates how to invoke the deployed AWS Lambda. Here is the code:

 

 

 

 

 

 

 

Here are the execution results:

The average elapsed time per employee (per request) is about 55 milliseconds including the time needed to send data to the AWS Lambda and return it back.

Instead of executing one request in a time, you can combine multiple request in a single batch to essentially improve the efficiency. Here is the example of the Java class “LaunchBatchClient” that split 1000 test-employees into batches with 200 employees in a batch and execute all batches:

Here are the execution results:

If you decide to undeploy your decision service and clean up your AWS, just click on the file “undeployLambda.bat“.

Deploying Your Decision Model. You can use the sample project “VacationDaysLambda” as an example of how to deploy your own model as an AWS Lambda function. Copy files “project.properties”, “deployLambda.bat”, and “undeployLambda.bat” to your own project. After adjusting “project.properties” (if necessary) you may simply double-click on “deployLambda.bat”, and then use the generated “testLambda.bat” to test your own service.