Workbench CLI tool commands
Use the Workbench CLI tool to make product module changes and push them to Root
This guide covers the full feature suite of the Workbench CLI tool. To set up the Workbench CLI tool, follow the Workbench setup tutorial first. To learn more about the configurability of product modules and workflows on Root, refer to the Product modules & workflows guide section.
Commands
rp create [api key] [product module name] [product module key]
rp create [api key] [product module name] [product module key]
Creates a new blank starter template product module on Root, and enables it for the organisation linked to your API key. The new product module is automatically cloned to a new directory on your local machine (see rp clone). Note: Product module keys must be unique across all organisations on Root.
Use cd
to navigate into the new directory in order to make changes to your new product module.
Optional: -h
or --host
flag
-h
or --host
flagDefaults to https://api.rootplatform.com/
. This optional flag will determine the host from where the product module will be created. To ensure you reference the correct domain, please refer to the domains section of the API reference.
Example
Below is an example of creating a product module and navigating into the new directory.
$ rp create sandbox_GDIwZGYxg5LTgMTE4YzWkhhKZV5xdVLZENTNt "Pet Insurance" pet_insurance -h https://api.uk.rootplatform.com/
Product module 'pet_insurance' successfully created on the Root Platform
Product module 'pet_insurance' successfully cloned into './pet_insurance' directory.
$ cd pet_insurance
rp clone [api key] [product module key]
rp clone [api key] [product module key]
This command creates a new directory and clones the latest draft version of your product module from Root to your local machine for local editing. This command is only used once for the initial setup of your product module on your local machine.
Use cd
to navigate into the new directory in order to use the other commands.
Optional: -h
or --host
flag
-h
or --host
flagDefaults to https://api.rootplatform.com/
. This optional flag will determine the host from where the product module will be cloned. To ensure you reference the correct domain, please refer to the domains section of the API reference.
Example
Below is an example of cloning a product module and navigating into the new directory. After this step is completed, all the other rp
commands can be used.
$ rp clone sandbox_NDIwZGYxg5LTgMTE4YzWkhhKZV5xdVLZENTNt dinosure -h https://api.uk.rootplatform.com/
Product module 'dinosure' successfully cloned into './dinosure' directory.
$ cd dinosure
rp pull
rp pull
This command pulls all files and configurations of your product module from Root and overrides the local files. By default, this command pulls the latest draft version, not the live version.
Optional: -f
or --force
flag
-f
or --force
flagUse the -f
or --force
flag to ignore the diff check and force the pull.
Warning: this overrides _all local files to match the version on Root exactly._
Optional: -l
or --live
flag
-l
or --live
flagThis optional flag will pull the live version from Root.
Optional: -ns
or --no-sort
flag
-ns
or --no-sort
flagBy default, the CLI tool will attempt to sort the keys of incoming JSON objects to match the key order of corresponding local JSON objects. You can choose to skip sorting of object keys and write them in the same order received from the Root platform by including this flag.
Example
$ rp pull
No changes to pull, local version is in sync with Root
rp push
rp push
This command pushes all the local files and configurations to Root which create a new draft version of the product module on the platform.
You can issue policies from a draft version over the API or on the dashboard in Sandbox
. To deploy the draft version to live, please contact the Root team (they will review your changes and action the deploy).
Optional: -f
or --force
flag
-f
or --force
flagUse the -f
or --force
flag to ignore the diff check and force the push.
Optional: -ns
or --no-sort
flag
-ns
or --no-sort
flagBy default, the CLI tool will attempt to sort the keys of incoming JSON objects to match the key order of corresponding local JSON objects. You can choose to skip sorting of object keys and write them in the same order received from the Root platform by including this flag.
Example
$ rp push
No changes to push, local version is in sync with Root
rp render
rp render
This command renders the document templates locally in the ./sandbox/output
directory. It compiles a PDF file for each valid HTML document in the ./documents
directory.
Productivity tip
For best use during active document development, use all three the
-m
,-p <policy-id>
and-w
flags simultaneously in order to generate new documents every time changes are saved. Open the document using Preview on Mac and it will automatically refresh. This results in a real-time view of the end-result.
Optional: -m
or --merge
flag
-m
or --merge
flagUse the -m
or --merge
flags to execute the handlebars and merge in the merge variables located in /sandbox/merge-vars.json
.
Optional: -p <policy id>
or --policy-id <policy id>
flag
-p <policy id>
or --policy-id <policy id>
flagSupply an ID for an existing sandbox policy ID with the -p
or --policy-id
option to fetch the corresponding merge variables. This will be ignored if the merge flag is set to false.
Optional: -w
or --watch
flag
-w
or --watch
flagUse the watch flag to enable live-reload that will re-render all the documents every time any of the template or merge-var files are saved.
Example
$ rp render -m -w
Documents successfully generated in the './sandbox' directory with merge-vars injected.
Watching for template or merge-var changes to re-render documents.
rp test
rp test
This command will run any tests specified in code > unit-tests
locally. Any files ending in .js
in this directory will be appended to the product module code files, after which the tests will be executed and test results returned in the console.
The test suite relies on Mocha & Chai for tests.
Productivity tip
For best use during active code development, use the
-w
flag to rerun the test suite every time changes are saved. This allows rapid feedback and encourages writing more tests.
Optional: -w
or --watch
flag
-w
or --watch
flagUse the watch flag to enable live-reload of the test suite when changes to either the code or test files are saved.
Example
$ rp test -w rp test -w
Started test suite.
getQuote
✓ should return an integer suggested premium
✓ should return a suggested premium of R115.17 (in cents)
2 passing (8ms)
Completed test suite.
Watching for code or test file changes.
rp lint
rp lint
This command will run eslint on the product module code.
Optional: -f
or --fix
flag
-f
or --fix
flagUse the -f
or --fix
flag to automatically apply the eslint fixes to the product module code.
rp logs
rp logs
This command displays the recent sandbox execution logs for the product module.
Optional: -c
or --count
flag
-c
or --count
flagUse the count option to specify the number of code runs to fetch logs for.
Optional: -f
or --function-name
flag
-f
or --function-name
flagUse the function-name option to specify a function name to filter the code runs. For example, validateQuoteRequest.
Optional: -p
or --policy-id
flag
-p
or --policy-id
flagUse the policy-id option to filter code runs by a specific policy id.
Optional: -s
or --status
flag
-s
or --status
flagUse the status flag to specify a status to filer the code runs
Example
$ rp logs
2023-04-14T05:44:28.281Z [complete] validateQuoteRequest
No logs
2023-04-14T05:44:30.071Z [failed] getQuote
2023-04-14T05:44:32.683Z [error] Product module code execution terminated due to a code error.
2023-04-14T05:44:32.680Z [error] Error: "Expecting value: line 1 column 1 (char 0)"
2023-04-14T05:44:32.675Z [debug] {
nominated_start_date: '2023-04-05',
name: { title: 'mr', first_name: 'John', last_name: 'Doe' },
gender: 'M',
date_of_birth: '1990-01-01',
occupation_type: 'employed'
}
2023-04-14T05:46:56.864Z [failed] validateQuoteRequest
2023-04-14T05:46:58.571Z [error] Product module code execution terminated due to a code error.
2023-04-14T05:46:58.568Z [error] Validation failed
rp generate
rp generate
This command generates workflow schemas, payloads and API Docs based on the Joi validation in the product module code. It saves the schemas and API Docs in the ./sandbox directory and creates payloads in the /payloads directory.
Optional: -w <step>
or --workflow <step>
-w <step>
or --workflow <step>
You can use the optional -w
or --workflow
flag to specify the workflow step for which you want to generate the schema. Currently, the supported steps are quote, application and alterations, which correspond to the quote, application and alteration workflows, respectively. The command will generate the workflow schema for the quote hook, application hook or alteration hooks, depending on the specified step.
Optional: -p <step>
or --payload <step>
-p <step>
or --payload <step>
You can use the optional -p
or --payload
flag to specify the workflow step for which you want to generate the payload. The command will generate the payload for the quote hook, application hook or alteration hooks, depending on the specified step.
Optional: -ad
or --api-docs
-ad
or --api-docs
You can use the optional -ad
or --api-docs
to generate the API reference for the quote and application step. The command will generate the API reference for the quote hook and application hook .
Example
To use this command, you need to refactor the validateQuoteRequest
and / or validateApplicationRequest
function to create the quoteSchema
or applicationSchema
variables, respectively. The example below is for the application step.
const applicationSchema = Joi.object().keys({
// The Joi validation schema can be completed here
})
const validateApplicationRequest = (data, policyholder, quote_package) => {
const validationResult = Joi.validate(
data,
applicationSchema.required()
);
return validationResult;
}
Defining the Joi schema
To correctly define Joi objects and ensure the accurate generation of components from Joi, please refer to the Schema components documentation.
By following these steps, you will be able to generate the expected output for the application step automatically, as shown below.
Workflow Schema
To generate the workflow schema for the quote hook or alteration hook, simply replace the word "application" with "quote" or "alterations" respectively.
$ rp generate -w application
Schemas successfully generated in the './sandbox' directory
Payloads
To generate the payload for the quote hook hook, simply replace the word "application" with "quote".
$ rp generate -p application
Payloads successfully generated in the 'payloads' directory
API Docs
To generate the API docs the following command will create the skeleton for both the quote
and application
steps.
$ rp generate -ad
API docs successfully generated in the './sandbox' directory
rp invoke
rp invoke
With this command you can quickly create a quote, application and/or policy in sandbox mode on Root. By default, the command completes all steps required to issue a policy (quote, policyholder, application and issue policy). Upon success, a link will be provided to view the policy on the Root dashboard.
To use this feature, you need to include quote and application payloads in the ./payloads
directory. These payloads represent the body of the API request that will be sent to the relevant Root endpoint. The payload files need to be named quote.json
and application.json
, respectively.
An example is provided below for the quote.json
file.
{
"type": "dinosure_demo",
"cover_amount": 10000000,
"cardio_fitness_level": "couch_potato",
"age": 40,
"smoker": false,
"early_warning_network_benefit": true,
"extraction_benefit": true
}
By default, the command will use the latest draft version of the product module to issue a policy. The policyholder will be created automatically based on the policyholder type allowed, as defined in the .root-config.json
file.
Optional: -q
or --quote
flag
-q
or --quote
flagCreate only a quote and display the quote package in the terminal.
Optional: -a
or --application
flag
-a
or --application
flagCreate a quote and an application and display the application in the terminal.
Optional: -c
or --claim
flag
-c
or --claim
flagCreate a policy and open a related claim.
Optional: -l
or --live
flag
-l
or --live
flagUse the live version of the product module.
Optional: -v
or --verbose
flag
-v
or --verbose
flagDisplay the quote, application and policy objects created during the policy issue flow.
Example
$ rp invoke --claim
Claim opened successfully! Click here to view on dashboard.
rp diff
rp diff
This command allows you to see line-by-line changes in your local product module definition, compared to the latest draft, in the command line interface.
Optional: -c
or --code
-c
or --code
This option allows you to view the changes made to code files specifically.
Optional: -ut
or --unit-tests
-ut
or --unit-tests
This option allows you to view the changes made to unit tests specifically.
Example
$ rp diff -c
Code files in ./code
--- main.js
+++ main.js
@@ -7,316 +7,316 @@
***************
*/
const dateOfBirthFromID = (id) => {
- let birthDate = moment(id.toString().slice(0, 6), "YYMMDD");
+ let birthDate = moment(id.toString().slice(0, 6), 'YYMMDD')
if (birthDate.isSameOrAfter(moment())) {
- birthDate = moment(`19${id.toString().slice(0, 6)}`, "YYYYMMDD");
+ birthDate = moment(`19${id.toString().slice(0, 6)}`, 'YYYYMMDD')
}
- return birthDate;
-};
+ return birthDate
+}
Optional -d
or --documents
-d
or --documents
This option allows you to observe the modifications applied to the document files (policy-schedule.html, certificate.html, quote-summary.html, anniversary-letter.html, member-certificate.html). In the case of the terms file, individual line distinctions will not be displayed; however, there will be an indication if the terms file has been revised.
Optional -ad
or --api-docs
-ad
or --api-docs
This option allows you to view the changes in the api-docs.yaml file
Optional -rm
or --read-me
-rm
or --read-me
This option allows you to view the changes in the README.md file
rp ai
rp ai
This command allows you to leverage off AI when building a product module. Create a .ai-auth file inside the root directory of your product module to use. For OpenAI requests, the file must be structured as follows:
OPEN_AI_API_KEY=sk-12345
.ai-auth security
Make sure to add .ai-auth to your .gitignore to keep your AI Key private.
Optional: -w
or --workflow
flag
-w
or --workflow
flagUses the provided .csv file name to generate a Joi schema in the /sandbox directory.
$ rp ai --workflow quote
Generating output via OpenAI....
Joi schema successfully generated in the './sandbox' directory
The .csv file must have the following header row located in a directory labelled /specifications.
field,data_type,requirement_type,validation,description,parent_key,parent_key_requirement_type
Here is an example file called quote.csv:
field,data_type,requirement_type,validation,description,parent_key,parent_key_requirement_type
cover_amount,Integer,Required,"[label: value]
One of [R6,000: 6000, R12,000: 12000, R18,000: 18000, R30,000: 30000, R42,000: 42000]",The chosen cover for the policy.,,
partner_included,Boolean,Required,"[true, false]",To indicate if a partner has cover on the policy.,,
date_of_birth,String,Required,"Must be in YYYY-MM-DD format in the past.
This is used to run through the Age validation business rule: B2",The date of birth of the main member,main_member,Required
title,Dropdown,Required,"[label: value]
One of [Mr:mr, Mrs:mrs, Miss:miss, Mx:mx, Sir:sir, Dr:dr, Adv:adv, Ms:ms, Prof:prof]",The title of the partner,partner,Required if partner_included is true else forbidden
//...etc
This will generate a Joi schema inside the /sandbox directory which you can then copy into your codebase. Note the structure will vary based on the AI Model's interpretation of the .csv file.
const partnerTitle = Joi.string()
.valid(['mr', 'mrs', 'miss', 'mx', 'sir', 'dr', 'adv', 'ms', 'prof'])
.required();
const mainMemberSchema = Joi.object({
date_of_birth: Joi.dateOfBirth().required(), // Assuming dateOfBirth() is a custom validation function
});
const partnerSchema = Joi.object({
title: partnerTitle,
});
const schema = Joi.object({
cover_amount: Joi.number()
.valid([6000, 12000, 18000, 30000, 42000])
.required(),
partner_included: Joi.boolean().required(),
main_member: mainMemberSchema.required(),
partner: Joi.when('partner_included', {
is: true,
then: partnerSchema,
otherwise: Joi.forbidden(),
}),
});
This schema is constructed based on the requirements and validations specified in the CSV. It includes:
- A `cover_amount` that must be one of the specified values.
- A `partner_included` boolean to indicate if a partner is included in the policy.
- A `main_member` object that requires a `date_of_birth`, which utilizes a custom `dateOfBirth()` validation function.
- A conditional `partner` object that is required if `partner_included` is `true`. This object requires a `title`, which must be one of the specified values. If `partner_included` is `false`, the `partner` object is forbidden.
Updated 6 months ago