Using the JavaScript toolbox item to call Sharedo API's - Workflow Toolbox

Whilst ShareDo toolbox provides access to a variety of blocks to assist you in building your workflows, there will be occasions where you require more control. This is what the JavaScript block is designed to give you.

Circumstances where you might use the JavaScript block include:

Calling a ShareDo API
Performing logic or manipulating variables for complex scenarios

Within the Workflow toolbox, you will find the "JavaScript" block under the advanced section.

Dropping this onto your canvas will reveal the following control.

Within this block, you are free to write JavaScript as you see fit. In addition, the ShareDo workflow runtime provides several helpers to assist you in this process.

Top Tip: You can understand how your custom JavaScript block might interact with the Visual workflow by clicking on the "Preview Script" button

Remember ShareDo's workflow engine also needs permission to access individual API's if your API returns a response such as:

Then you will need to assign the relevant permission to the EE App in Admin / Manage Identity Server.

Top Top: When calling an API this will often fail for various reasons. In order to see the underlying issue and hence give yourself more information you will need to change the default logging level of the application (non production environments only). This is done via the Global Feature “Error status handling”

Accessing workflow variables	You can access workflow variables using the syntax ctx.<variableName> where the variables have been created in the Data section of your workflow definition.
Accessing event data	When your workflow is associated with an event then you can also access the event data that is passed using the syntax ev.Data,<variableName> Top Tip: if you want to understand the event data that is passed in then within you JavaScript block you should write this to the log using. `log.Information(ev.Data.ToString());`
Logging information to the workflow monitoring console	ShareDo will log a significant amount of information to the workflow diagnostics window as part of normal processing however if you want to supplement this information then use the following command. `log.Information(<information to be logged>);`
Calling REST APIs using the HTTP Client	ShareDo provides an HTTP client to enable you to call ShareDo APIs. In normal processing you will typically want to: Pass Workflow variables to the API via a model Call the API Extract values from the response into workflow variables Branch the workflow in the case that the API call fails The following script provides an example of this. var model = { "parentShareDoId": ctx.matterId, "workItem": { "ShareDoTypeSystemName": ctx.proceedingWorkTypeSystemName, "title": "1st Instance", "description": " ", "reference": "12345" }, "aspectData": { "proceedingDetails": { "parentId": ctx.matterId, "litigationDirectionId": ctx.litigationDirectionId, "jurisdictionId": ctx.jurisdictionId, "courtTypeId" : ctx.courtTypeId, "litigationReasonId": ctx.litigationReasonId, "courtCaseReferenceId": "12345", "participantsToCopy": [] } } }; let response = ShareDo.http.post("/api/v1/public/workItem/", model); if (!response.success) { ctx.proceedingCreatedFlag = false; log.Information("API call failed"); try { log.Information("Response was: " + JSON.stringify(response.body, null, 4)); } catch (e) { // Body wasn't an object (could be bad request, 403 etc) log.Information("Response was: " + response.body); } } else { // Store the ShareDo ID returned log.Information("Response was: " + JSON.stringify(response.body, null, 4)); ctx.proceedingCreatedFlag = true; ctx.proceedingId = response.body.workitem.id; } In addition to using your workflow variables in script via `ctx.<variable name>` you can also set them back - for example: `ctx.myVariable = httpResult.body.someValue; ctx["myVariable"] = httpResult.body.someValue;` If you need to see the entire payload returned from the API: `try { log.Information("Response was: " + JSON.stringify(response.body, null, 4)); } catch (e) { // Body wasn't an object (could be bad request, 403 etc) log.Information("Response was: " + response.body); }` The reason for the try/catch is some responses may return a JSON payload to work with, others may not. In this case, it will log the JSON response or the raw body depending on which one is applicable.

Related Articles