or How to best manage large Python sources in SAS Intelligent Decisioning Decision Flow in Intelligent Decisioning   SAS Intelligent Decisioning (ID) is great to design and build decisions. It is a great tool to operationalize Analytics. In a graphical (low code no code) manner you can easily design, build, test and deploy decision flows. However sometimes it may be necessary to add some code to a decision flow. In SAS Intelligent Decisioning you can do this by adding SAS DS2 or Python code.   The code is stored in code files in ID. Python code files are meant for manageable Python scripts that are not too large. If we want to execute Python scripts which have many lines of code and are broken up into several functions it may be better to develop, test and maintain this code in a dedicated Python environment. The code should then be loaded into SAS Intelligent Decisioning and should have a defined API which is called from within a Python code file in ID.   Long Python script in SAS Intelligent Decisioning. Python scrip with package loaded from Git. In this blog I’m going to show how we can write and version a Python module in a Python development environment and execute the module as part of a decision flow in SAS Intelligent Decisioning.   Python development In general Python developers can build and test their Python module in an environment of their choice, for example VS Code. The development environment should meet the programmer’s needs where they feel comfortable and where they are most productive in.   For our scenario we are going to build a simple “Hello Word” program using VS Code to edit & test the code... Edit & test code in VS Code.   ...and to version it in GitHub. Version code in GitHub from VS Code. The Python module needs to be versioned in GitHub/GitLab. The development environment should be connected to Git either directly via the code editor (Git-plugin) or indirectly through a Git desktop or Web UI. The project in Git needs be configured to create a Python package as this will allow us to load the package into SAS Intelligent Decisioning.   Release in GitHub. When the Python code is written, tested and ready to be used we build a release in Git which we are going to reference from SAS Intelligent Decisioning.   Creating a release also means we have a dedicated commit point which is ready to be used and is not going to change going forward. Installing the Python code from a release (tarball or zip file) also means we don’t need Git for the installation, as it is not available in the Viya installation.                     Using the Python code in SAS Intelligent Decisioning   Publishing Destination When a decision flow is created, we need to publish it to an environment from where we are going to execute it. An Administrator can setup different publishing destinations which then can be used in SAS Intelligent Decisioning.   When we publish to a Container Publishing Destination  we build a SAS Container Runtime (SCR). SCR is a lightweight Open Container Initiative (OCI) compliant container that scores SAS models and decisions. These containers can be used in your cloud environment as standalone scoring engines or incorporated into an execution pipeline.   When we publish a decision flow to a Container Publishing Destination, we can dynamically install Python packages which are added to the container’s Python environment when it is build. We are going to use this feature to install our Python package that resides in Git.   Note: To install a Python package from Git you need to have Viya 2023.12 or later.   Using Python code from Git repository When we open a new Python code file in SAS Intelligent Decisioning there are three docstrings at the top of the code file. One docstring is for “DependentPackages” where we can state Python packages that we want to be installed in the container runtime when it is built.   To install a package from Git we copy the URL of the release archive file from Git, and generate a personal access token in GitHub/GitLab. In the DependentPackages docstring we paste the Git release archive URL together with the leading Git access token. Python code file referencing Python package in GitHub.  There are different ways of calling a release from Git: Tag: Call a specific release via its tag (as we did above): GitHub: https://<token>@<github-repository>/archive/refs/tags/<tag>.tar.gz GitLab: https:// oauth2:< token >@<github-repository>/archive/refs/tags/<tag>.tar.gz Latest Release: Always trigger the latest release when publishing the decision flow to the Container Publishing Destination: GitHub: https://< token >@<github-repository>/archive/refs/heads/main.tar.gz GitLab: https:// oauth2:< token >@<github-repository>/archive/refs/heads/main.tar.gz Snap-Shot Number: To ensure we always use the same physical git archive; we can use the release snap-shot number. Releases could be deleted and re-build using the same tag. Using the snap-shot number will ensure that we always get the same code as the snap-shot number will change if the release gets re-build. GitHub: https://< token >@<github-repository>/archive/<snap-shop number>.tar.gz GitLab: https:// oauth2:< token >@<github-repository>/archive/<snap-shop number>.tar.gz Release Snap-Shot Number.   When we have put the release URL in the docstring, we can reference the python package by its name via the import statement like any other Python package. In our case the package is called helloworld. We import the package and then call its function hw() from inside the code file’s execute() function. Calling Python package from within ID Python code file. We call the entry point of the Python package from the python code file in ID. In terms of the decision flow the Python package is a “black box”. We call it with its input parameters and receive the defeined return parameters. The way it works internally is maintained and managed by the Python developers in the Python development environment.   When we have written the Python code file we can add it to the decision flow in Intelligent Decisioning. Python code file added to decision flow.   Testing As the Python package is installed in SCR when the container is built, it is not available in SAS Intelligent Decisioning’s Python environment and therefore we can’t test the decision flow in ID via the Scoring/Test or Scoring/Scenarios tab. In order to test the decision flow, we need to publish it first. Publish decision flow to container destination.   When the decision flow is published, go to the Scoring/Publishing Validation tab. In there, click on the test name for the published decision flow and set the table with the input data for the test. The test table column names and the input parameter names need to match in order to run test the decision flow. Validate published decision flow. When the test is finished, we can click on the results icon to check the output from the decision flow. Decision flow test run result. When the test result is as expected, the decision flow is ready to be used.   Note: To test a published decision flow from within SAS Intelligent Decisioning the publishing destination needs to be configured respectively.   Conclusion SAS Intelligent Decisioning works great with open source like Python. The Python editor in the Python code file in ID is good to develop and test small to medium Python scripts. If you envisage to execute Python scripts in ID with many lines of code, you should consider an external Python development environment and call the Python code as described in this blog. This will help you to maintain the Python code in an appropriate way and to create a better manageable decision flow after all.     ... View more

In SAS Intelligent Decisioning you can write your own custom functions to enhance its set of functions if you have code that you want to use more often or in different Decision Flows. Sometimes it may be useful to have one function that accepts different sets of input parameters. So, you can call the same function in a different way depending on its use case. For this a programming language needs to support ‘function overloading’. SAS DS2, the programming language in Intelligent Decisioning, does support ‘function overloading’.   Writing overloading functions To write an overload function in Intelligent Decisioning we have to use a custom context file rather than writing a custom function directly in Intelligent Decisioning. To create a custom context file, go to Code files in Intelligent Decisioning click on ‘New Code File’ and choose file type ‘Custom Context’ In the file you can write different variants of your overload function which have the same name but different input parameters. In this example we have a function (or method as it is called in DS2) that calculates the fuel economy for a given list of vehicles. We have two flavours of the same function: The fist specification takes two input parameters. One parameter (datagrid) with a list of vehicles, the driven distance, and the used fuel. A second parameter (datagrid) to hold the output with calculated fuel economy for each vehicle in parameter one. We calculate the fuel economy by reading the necessary values from parameter one and write the result into parameter two. The second specification takes only one parameter, the same as in the first specification. But in this variant of the function, we add columns to the list of vehicles that are passed in and output the fuel economy to the list.   Calling overloaded functions When we have written the function (fuelEconomy()) we can call it from a DS2 code node, a custom function or from a Rules Set. Depending on the use case we can call the function in two different ways. To call a function that is in a custom context file we need to call it via its qualifier ‘application’ using the format: application.method_name(arguments); In a Rule Set for example we can call the function like this: We pass in the list of vehicles in parameter vehicleList: And receive the fuel economy in parameter ecoList:   Alternatively, we can call the function like this: Where we only pass in the parameter vehicleList: And receive the fuel economy also through parameter vehicleList: To test the Rule Set we have to make the Rule Set aware of the custom context file, so it can find the function we have written. In the Rule Set go to Properties and set the custom context file in field: Test custom context. (The same applies when testing DS2 code files)   Associating a Custom Context File with a Decision Custom Context files can only be used with published Decision Flows and not Rule Sets. For a Decision Flow to pick up a custom context file we need to associate it with the Decision Flow where we use it. In the Decision Flow go to Properties to set the custom context file. There are two entries for custom context files as you can use different files for executing the decision flow in CAS or MAS respectively. Summary To enrich the set of functions in Intelligent Decisioning you can write overload functions by using Custom Context files. These functions can then be called in DS2 code files, custom functions, and Rule Sets. ... View more

There are many definitions of data quality. We can say that data is generally considered high quality if it is "fit for purpose” or “fit for its intended uses” to support your processes including analytics where we aim to have a high data quality to achieve the best possible results. We measure data quality based on different data quality characteristics like accuracy, completeness, validity and more. These data quality characteristics are called data quality dimensions. In this blog I’m going to show how we can use SAS Intelligent Decisioning to build data quality monitoring rules.   Create data quality monitoring rules. In Intelligent Decisioning we build the monitoring rules in three steps: Data quality business rules Data quality fields rules Monitoring Tasks Data quality business rules The business rules describe the data quality rules for the different quality dimensions. The rules are implemented as Rules Sets in Intelligent Decisioning. If possible, the rules are written to be reusable, so that a rule can be used for different fields. For example, we can have a rule named “Completeness_String” where we check if a character field has 0 length or is null. This rule can then be used for many character fields for dimension Completeness. We may also have rules which are specific to certain fields so that we end up having reusable as well as specific rules for different dimensions and fields. As we use Rule Sets in Intelligent Decisioning to build the business rules we can mostly build the rules without writing code. We just “assemble” generic if-then-else statements which are not language specific at this point.      However, for more sophisticated rules we can also use SAS DS2 code within the Rule Set which offers a lot of functions out of the box like functions for regular expressions, the Quality Knowledgebase (QKB) and more to build the business rules to perform all necessary checks.     All data quality business rules that we write follow the same pattern. This means we have two input parameters which we pass through plus two additional output parameters. The input parameters are The Record ID for the record where we measure the data quality. The Field Value that is being check. The additional output parameters are A Boolean parameter to state the result if the rule was triggered or not. A parameter to carry the rule name. This is to identify the rule name for a fired rule when we visualize the monitoring result later in a Data Quality Dashboard.     When we have built a business rule, we can test it within Intelligent Decisioning by streaming through some test data, to ensure the rule works as desired before we use it in production.     We can also version our rules in Intelligent Decisioning which helps us to govern and maintain the rules through their lifecycle.   Data quality field rules When we have written the data quality business rule, we are going to combine all rules that we need for one field or table column where we want to check its data quality.     To build the fields rules we are using decision flows in Intelligent Decisioning. For each field where we are going to perform quality checks, we build one decision flow. In the decision flow we call the specific quality business rules (rule sets) hat we want to check for the field. After a business rule was called, we evaluate its result. If no quality dimension rule was fired (the result status was True), we are going to call the next business rule for the next quality dimension and do the same when we check the result for this business rule. As soon as a rule for a dimension was fired, we l leave the decision flow, as we don’t want more than one dimension to fail at a time. When we have built the field rule, we can then test the rule by streaming through some test data, to ensure it works as desired, like testing the business rule before. And like business rules, we can version the field rules in Intelligent Decisioning to support the government and maintenance process.   Monitoring Tasks When we have built the necessary field rules, we are going to build the monitoring tasks. Monitoring tasks describe all fields of an entity for which we are going to check the data quality. In a decision flow we combine all field rules for one entity by calling each field’s appropriate field rule.     Like with business rules and field rules we can also test the monitoring task in Intelligent Decisioning as well as version them. Using the right monitoring task in production.   For the decision flows we can use the approver workflow that is part of Intelligent Decisioning and helps to ensure that only tested and approved monitoring tasks are going to be used on the production data.       When a new monitoring task (decision flow) is created, Intelligent Decisioning automatically starts a workflow with several stages to control that a dedicated person is involved at the right time to develop, test, and approve the monitoring task. When a monitoring task has reached the status Deployed in the workflow it is ready to be used for measuring the data quality in production.   Summary Intelligent Decisioning is a great tool to support you in monitoring data quality in SAS Viya. I have described one way to achieve this task but there are other ways too, depending on your requirements. In the next post I’m going to talk about how we can run the monitoring tasks using Studio Flow in SAS Studio. ... View more

In Intelligent Decisioning variables can have different data types. One data type is a DataGrid. A DataGrid is a table and allows us to build one to many relationships on decision records. For example, you could have a person with several addresses.   Decision Record: Name Date of Birth Address     Dave 1998-05-02 Street Town Postal Code     10 High St Brighton BG1 3ER     11 Downing Rd London  LO1 5YY   In the above example you would put the address information in a DataGrid and perform all necessary address operations on the DataGrid. For this Intelligent Decisioning supplies 70+ DS2 functions to work with DataGrids. There are functions for different categories like create, update, or delete, to get meta information, to retrieve values from a DataGrid, to perform statistical operations, and more.   However, sometimes we have decision flows where we must add some logic in a code node. If the code node is a Python code node and we want to work with a DataGrid in the Python code, we can’t use the DS2 DataGrid function, but we can still work with the DataGrid in Python.   Work with DataGrids in a Python code node Let’s have look how to work with DataGrids in a Python code node in Intelligent Decisioning. There are basically three steps involved: Serialize the DataGrid to pass it into the Python code node. In Python Convert the serialized DataGrid into a Python list object Work with the DataGrid in Python Serialize the list object and return it back to the decision flow Convert the serialized list object from Python into a DataGrid in the decision flow Data Grid structure Technically DataGrids are json objects and stored in a character variable on the decision record. A DataGrid json string has the following basic format: [{"metadata”: [column-definitions]},{"data":[column-data]}] The column definitions are name-value pairs separated by commas: {"column1-name":"data-type"},{"column2-name":"data-type"},... The data for each row of the DataGrid is specified in square brackets with commas between each value: [column1-data, column2-data...]   Pass DataGrid into Python code node As we cannot pass a DataGrid object directly into a Python code node in Intelligent Decisioning, we need to serialize the DataGrid first and save its JSON structure in a character variable. In this example I use a Rule Set. The Rule Set has one input parameter and one output parameter: Input parameter: The DataGrid to be serialized. Output parameter: The character variable to hold the DataGrid json structure.   We add an assignment statement to the Rule Set to retrieve the json structure for the DataGrid by calling the DataGrid function dataGrid_toString() and pass the output of the function to the Rule Set output parameter. dgJSON= dataGrid_toString(dg)     Work with the DataGrid in Python Next, we use the Rule Set in the decision flow before we call the Python node to prepare the DataGrid in order to input it into the Python code node.     We pass the serialized DataGrid string (addressJSON) into the Pyhton code node as input parameter. In the Python code we use json.loads() from the Pyhton json library to load the DataGrid into a Python list object. Once we have loaded the DataGrid into a list object we have full access to the DataGrid and can perform all necessary operations.   In our case we validate each address row by calling an external address validation service. We add a new column to the DataGrid and store the validation result in the DataGrid.     To send the changed DataGrid back to the decision flow we need to serialize its Python list object by calling json.dumps() and return the serialized object via Python return.             Convert Python list object into DataGrid In the decision flow we receive the updated DataGrid as serialized JSON string. We pass this JSON string into a Rule Set to convert it back into a DataGrid.     The Rule Set has one input parameter and one output parameter: Input parameter: The character string holding the serialized Python list object. Output parameter: The DataGrid created from the serialized input string.     We add an assignment statement to the Rule Set to convert the json structure into a DataGrid by calling the DataGrid function dataGrid_create() and output the DataGrid from the Rule Set. dataGrid_Create(dg, dgJSON)       Now we can continue working with the updated DataGrid in the decision flow.   Summary We discussed the steps involved working with DataGrids in a Python code node. This way we can conveniently use DataGrids in Python if needed which enhances the capabilities of Intelligent Decisioning.   ... View more

If you are streaming data using SAS ESP and your data stream involves making decisions, you can build Rulesets and Decisions in SAS Intelligent Decisioning and use these in your data stream. ESP can invoke the code that is generated by SAS Intelligent Decisioning and execute the code in its Micro Analytic Service (MAS) engine. In this blog I discuss the steps required to use Rulesets and Decisions in an ESP data stream.   Receiving code for Rulesets & Decisions If you have a Ruleset or Decision in Intelligent Decisioning that you’d like to use within a data stream in ESP you need to export the DS2 code that is generated by Intelligent Decisioning and point ESP towards the code to execute it. The steps to export the code are very similar for Rulesets and Decisions. To export code from Intelligent Decisioning we are going to use the Viya REST API to: Obtain an access token to SAS Viya Receive the ID for the required Ruleset or Decision Receive the Intelligent Decisioning DS2 code for the Ruleset or Decision Obtain an access token to SAS Viya Before you can start using SAS Viya APIs, you must have your SAS administrator register a client identifier. The SAS Logon OAuth API uses OAuth2 to securely identify your application before it connects to the SAS Viya platform. See Registering clients for information on how clients are registered. Once a client is successfully registered, the SAS administrator provides you with the client identifier and client secret to authenticate an API request. To obtain an access token call: http://{{ViyaServer}}/SASLogon/oauth/token       Value Setting Comment Method POST             Authorization Username Set to <Client Identifier> Use Basic Authorization   Password Set to <Client Secret> Use Basic Authorization         Header Content-Type application/x-www-form-urlencoded           Body grant_type password x-www-form-urlencoded   username Set to <Viya username> x-www-form-urlencoded   password Set to <Viya password> x-www-form-urlencoded   If successfully executed, you will get an access token which is to be used for all other REST calls.   Receive the Ruleset or Decision ID We need to get the ID for the Ruleset or Decision that we want to use in ESP. The ID is required for the REST Endpoint to receive the DS2 code. To get the ID, call the appropriate Endpoint for Ruleset or Decision: Ruleset: http://{{ViyaServer}}/businessRules/ruleSets Decision: http://{{ViyaServer}}/decisions/flows     Value Setting Comment Method GET             Parameters filter eq(name,"<Ruleset Name>") Set <Ruleset Name> to the name of the Ruleset you want to look up.         Header Authorization Bearer <Access Token> Unsure to have a space Bearer and the access token.   Content-Type application/json     If successfully executed, you will receive the Ruleset/Decision ID in the field “id” in the “items” list.     Receive Intelligent Decisioning code With the just received ID we are going to export the DS2 code for the Ruleset or Decision. To get the code call the appropriate Endpoint for Ruleset or Decision: Ruleset: http://{{ViyaServer}}/businessRules/ruleSets/<ID>/code Decision: http://{{ViyaServer}}/decisions/flows/<ID>/code Set <ID> to the value of the Ruleset or Decision ID we just received.   Value Setting Comment Method GET             Parameters codeTarget MICROANALYTICSERVICE     lookupMode inline     isGeneratingRuleFiredColumn false           Header Authorization Bearer <Access Token> Unsure to have a space Bearer and the access token   Content-Type text/vnd.sas.source.ds2     If executed successfully, you will receive the DS2 code for the Ruleset or Decision.     Preparing the code The steps for getting the code for Rulesets or Decisions are very similar. But for Decisions we need to do some extra steps.   Ruleset Code For Rulesets we copy the DS2 code from the REST call into a file, save the file with a descriptive name, i.e. the name of the Ruleset, and move it to a location where ESP can access it.   Decision Code For Decisions, the code usually consists of several DS2 packages. One DS2 package for each node in the decision flow. We need to split the code that we received from Intelligent Decisioning by saving each package in a separate file. When naming the files, good practice is prefixing the files with the decision name and suffix it with the appropriate node name like <decision name>_<node name>.ds2. To know which package belongs to which node in the decision flow you find a comment above each DS2 package statement with the appropriate information. The last package in the Intelligent Decisioning code is the decision flow entry point. Usually I give this file the name of the decision like <decision name>.ds2. When you have split the DS code into several files, you move the files to a location where ESP can access them.   Invoke Intelligent Decisioning Code in ESP As we have saved the code into files and moved them to a location that ESP can access, we can now invoke the code from our ESP project.   For Rulesets we need to register the ruleset code file we saved and for Decisions we need to register all files that we saved, the file form the decision flow as well as the files for the decision nodes.   In ESP we open the project and go to Micro Analytic Service Modules at the project level. We add a new Micro Analytic Service Module for each file and fill in all required fields. Field Value Comment Name <Set a descriptive name> I.e. name of the ruleset, decision or decision node *** See comment Note below! *** Language DS2   Function names execute This must be set to ‘execute’. The entry point method into each DS2 package is called ‘execute’. Code source External file   External file <DS2 code file> The name of the DS2 code to register including the directory where the file is stored. It is good practice to use a Token to point to the directory where the code file resides.   Note: ESP will load the DS2 code files in alphabetical order. Therefore, you must ensure that the main package of a decision flow is the first in the Micro Analytic Service Modules list in ESP. You can best achieve this by adding a number prefix to the Name like 01_, 02_,etc.     Add a Calculate Window to the data stream to invoke the RuleSet or Decision. At Settings choose Calculation = User-specified. At Handlers select the Ruleset source or the main module for the Decision flow and make sure the field values are set correctly. Field Value   Handler type SAS Micro Analytic Service   Module <Ruleset Name> or <Main Decision Module> Choose the name that you’ve set for the Decision Ruleset. Function execute       Save the project and you are ready to run it in Test mode to check if it works as desired.   Conclusion Intelligent Decisioning is a great place to build and maintain rules and decision logic. Executing decision flows in an ESP project is a great way to split decision logic from the more technical part of the ESP project. This gives people with less technical knowledge the opportunity to concentrate on the more logical part of the project. Decisions can be built and tested independent from the rest of the ESP project and once ready they can be integrated into the ESP project. ... View more

When creating a Decision Flow in Intelligent Decisioning, you can test the decision logic within Intelligent Decisioning to make sure the decision works as desired. You can also publish the Decision Flow to MAS and validate its behaviour running in MAS. But it is useful and often necessary to get an understanding how MAS can cope with the Decision Flow in production. What happens when many users call the Decision Flow at the same time? Can MAS cope with it, especially if MAS is serving several decisions, rule sets or analytical models at the same time. You need to be able to run a load test and measure the performance to see what impact the Decision Flow has on your MAS environment. Load testing allows you to predict how a Decision Flow will perform before it is moved into production.   There are many load-testing tools out there. We are going to look today at Locust. It is open source, Python based and easy to use.   The idea of Locust is that a swarm of locusts (users) will attack your webservices. The user (locust) behaviour is defined in a Python script and the attack is monitored in real-time via a web UI. This allows you to identify bottlenecks and helps to configure the environment appropriately.   Setup Locust Locust runs on Linux and Windows and its installation is straightforward. The current version requires Python 3.6 or later. Once we have installed Python, we can install Locust by running:   pip3 install locust   If we use Anaconda Python, we can install Locust running:   conda install -c conda-forge locust   When we have installed Locust, we can check that the installation works by running:   locust --help   This will give us an output that look like this:   Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   Load Test When we have successfully installed Locust, we can run load tests on Decision Flows (or any other module) in MAS. The MAS environment, where we do the load test, needs to have the same setup (or at least very similar) as the production environment. Otherwise the test results won’t be very meaningful Assuming we have created a Decision Flow, have tested it to ensure the logic works as desired and we have published the Decision Flow to MAS where we did a test run to make sure it will execute in the published environment. We can then prepare a simple Python script to run a load test on the Decision Flow.   Locust Script For our test we are going to use Users and Tasks in Locust: A User is a virtual user that is performing one or more Tasks. A Task is a work unit a user is doing. In our case calling a Decision Flow. For the test scenario we are going to write a test script where a user logs on to Viya to get an access_token and then calls a Decision Flow repeatedly. For this, we write a locust file, which is a regular Python script, to setup the test scenario. From locust we import HttpUser, task and between as these are needed in the test script:   from locust import HttpUser, task, between To define the user, we write a class that inherits class HttpUser, which allows us to make web calls. class MAS_User(HttpUser): Within the class MAS_User we define the work the user is doing as functions. At first the user needs to get an access_token from Viya. As we only need to do this once, we use the default function on_start() that comes with class HttpUser. The function on_start() is called when a user is created and before any Task is executed. Within on_start() we call the Viya web services to receive the access_token which is then used to authorize when calling the Decision Flow.   def on_start(self): To create a Task for a user we create a Python function within the class MAS_User and give it a meaningful name. To make the function a Task, we add the @task decorator on top of the function.   @task(1) def approve_contract(self):   @task takes an optional weight argument that can be used to specify the task’s execution ratio. For example, if we have two tasks, @task(3) and @task(6), then @task(6) will have twice the chance of being called as @task(3). To call a web service from class MAS_User we use appropriate functions from its parent class HttpUser. HttpUser has a set of functions to perform web requests. This set of functions is a slightly extended version of python-request’s requests.Session class and mostly works exactly the same. To call a Decision Flow, we use the this code:   url= "/microanalyticScore/modules/approve_contract/steps/execute" response= self.client.post(url, headers=self.headers, data= payload, name=mas_module) We can also set wait_time on class MAS_User to make the user wait between a minimum time and a maximum time after each task is executed. To assign a time interval to wait_time we use the Locust function between(). Below we set a time interval to wait between 1.5 and 3.5 seconds after each task.   wait_time= between(1.5, 3.5) When we have written the test script, we save it under the name locustfile.py, as this is the default name for a script Locust is looking for. We can use a different name but would have to tell Locust when starting the locust server.   Finally, the locustfile.py file could look like this for calling a Decision Flow in MAS:   import base64 import json from locust import HttpUser, task, tag, between user= 'sasdemo' password= '********' clientId= 'mas.client' clientSecret= '********' class MAS_User(HttpUser): headers= {'Authorization': '', 'Content-Type': 'application/json'} wait_time= between(5.5, 10.0) def on_start(self): Authorization= clientId + ':' + clientSecret Authorization64= base64.b64encode(bytes(Authorization, 'utf-8')) url = "/SASLogon/oauth/token?grant_type=password&username=%s&password=%s" % (server, user, password) response= self.client.get(url, headers= {'Content-Type': 'application/json', 'Authorization': 'Basic ' + Authorization64.decode('ascii')}, name= 'Get access token') self.headers['Authorization']= 'Bearer ' + json.loads(response._content)['access_token'] @task(1) def approve_contract(self): mas_module= 'approve_contract' mas_input={ "inputs": [ { "name": "contract_id_", "type": "decimal", "value": 10007 } ] } url= "/microanalyticScore/modules/%s/steps/execute" % (server, mas_module.lower()) payload= json.dumps(mas_input) response= self.client.post(url, headers=self.headers, data= payload, name=mas_module)   Run Load Test When we have written and saved locustfile.py, we can run the load test and monitor the results in Locust’s web UI. To start the locust server, we open the Linux command line in the directory where we saved locustfile.py and run locust:   locust Locust starts and shows some output that it is started. We then open the Locust Web UI to start the load test. In a browser we call the server where locust is running on port 8089   http://:8089/   A UI is coming up to set the parameters for the load test: The total number of users that will attack our MAS server. The spawn rate - the number of new users per second added to the test until the total number is reached. The IP address where MAS is located. If Locust and MAS are running on the same Linux server, we can use “localhost” or “127.0.0.1”.   By clicking on Start swarming we start the test by launching simulated users to call our Decision Flow. As the web services are called, we can monitor their behaviour in the Locust UI.     On the Statistics tab in the UI we get information like: Request — Total number of requests Fails — Number of requests that went wrong Median — Response time in ms for 50 percentile 90%ile — Response time in ms for 90 percentile Average — Average response time in ms Min — Fastest response time in ms Max — Longest response Time in ms Average size — Average size in bytes for a response Current RPS — Current Requests per Second Current Failure/s — Number of failures per second This give us an understanding how the web-services are performing. On tab Charts we get charts on:   Total Requests per Second     Response Time Number of Users We can also download the data via tab Download Data. There are various ways of monitoring the performance of our Decision Flow (and other MAS modules if we have added them to the test scenario in locustfile.py) to identify bottlenecks and to help us configuring our environment appropriately.   Command Line There is also a command line interface for Locust from where you can configure and start a test and write the output to csv files. To get a list of command line options type for help…   locust -h   … or see Locust documentation. This makes Locust a compelling tool to be used in CI/CD pipelines, which I’m going to talk about in an upcoming blog.   Conclusion If you have some Python skills, Locust is a convenient tool with a small footprint to run load tests on web services. You have seen a basic example how to run a load test on MAS using Locust. There are, of course, other and more complex ways how to write test scripts. Just have a look at the Locust documentation to see different ways of writing test scripts and to learn more about what you can do with Locust.  ... View more