Setting Up the Sandbox Connector
This topic describes how to configure process definitions to handle requests from transaction types when they are being tested in a development sandbox.
Sandbox Connector Overview
Sandbox connectors enable you to test transaction types, such as permits, planning application types, and business license types, while they are still in draft-mode being designed and tested within the development sandbox. With the Sandbox Connector, you can design an intake form and test it, end-to-end, without needing to publish it. Without the Sandbox Connector, the transaction type intake form will not be able to trigger interaction with the associated workflow process definition.
To complete the integration of the Sandbox Connector, you need to perform these tasks for all existing process definitions:
Create a Sandbox Connector.
Update the process definition to use the Sandbox Connector.
This process will need to be completed for all new and existing process definitions.
For more information on sandboxes and testing draft intake forms in the sandbox, see Working with Sandboxes and Testing Intake Forms.
Creating the Sandbox Connector
To create the Sandbox Connector:
Open the process definition.
Select
.On the Create REST Connector dialog box, enter these values.
Page Element
Value
Name
SandboxConnector
Base URL
{your host}/fscmRestApi/pscresources/11.13.18.05/dynamic/DynamicRequests
Click Create.
Click Edit to display the Configuration section.
On the General tab, make sure the base URL is correct.
Select the Security icon, and enter the proxy user created to access the Oracle Permitting and Licensing data.
Select either OAuth or Global Credential, the recommend options. For more information on the proxy user and credentials, see Setting Up OCI Process Automation Proxy User.
Select the Visibility tab and choose how you want the integration to appear.
Show operations is recommended.
In the Resources box, click Add.
Enter these values for the resource.
Page Element
Value
Name
DynamicTransactionResource
{baseURL}
Blank
At the top of the Operations grid, click Add, and select POST operation.
Select the row for the postDynamicTransactionResource operation.
In the Resources > Resource box, scroll to the Request/Response area, the Request button will already be selected. Click the plus sign (Create a business object).
In the Import Business Object from JSON dialog box, enter these values and click Import:
Page Element
Value
Name
RequestDynamicResource
JSON
Select Schema and add the following JSON.
{ "$schema" : "http://json-schema.org/draft-04/schema#", "type" : "object", "properties" : { "resourceName" : { "type" : "string" }, "method" : { "type" : "string" }, "payload" : { "type" : "string" }, "payloadnv" : { "type" : "string" }, "path" : { "type" : "string" } } }
Click the Response button, and from the Body drop-down list, select BusinessData.ResponseTransactionData.
Click Apply to save your changes.
Update the Process Definition
In this task you will update:
All calls from the getTransactionData and patchTransactionStatus operations of the Transaction Connector have to include the postDynamicTransactionData operation of the Sandbox Connector.
All corresponding data associations.
To update getTransactionData calls:
Select Processes in the left-hand navigation to display the process.
Expand the Get Transaction Data node in the process definition, select the transaction data node, and select Open Properties.
Note:This node can have other names, such as Get Application, Get Permit Data, and so on. It is typically the first system task in the process definition, where the process definition gets the required initial data, including transaction type, transaction data, and so on.
From the Type drop-down list, select Service Call, and click the Configure button.
On the Configure dialog box, click the search icon for the Integration field, and select SandboxConnector.
With SandboxConnector displayed in the Integration field, update these values, and click OK:
Page Element
Value
Resource
DynamicTransactionResource
Operation
postDynamicTransactionResource
Return to the process definition by collapsing the properties pane, select the same node you selected in the steps above, and this time select Open Data Associations.
Note:You may notice warning text referring to undefined variables, which is what you will resolve in the following step.
On the Data Association page, make sure the Input tab is selected, and for the field that reads New Association, enter “GET” and then update the data associations accordingly:
Page Element
Value
transaction.resourceName
body.resourceName
transaction.transactionKey
body.path
“GET”
body.method
Select the Output tab and add these values:
Page Element
Value
bodyOutput
transactionData
Repeat these steps for all calls to the getTransactionData in the process definition.
To update patchTransactionStatus calls:
Use same steps above for updating the properties and data associations.
Enter these input data associations:
Page Element
Value
transaction.resourceName
body.resourceName
transaction.transactionKey
body.path
"Status:Accepted"
body.payloadnv
"PATCH"
body.method
Enter these output data associations:
Page Element
Value
bodyOutput
transactionData
Use the
Integration JSON Payload Attributes
The integration requires a POST operation request from the OCI Process Automation process definitions.
The payload attributes are:
Attribute |
Description |
---|---|
resourceName |
Dynamic resource name, such as the permit type. |
method |
REST method for the dynamic resource, such as GET, POST, PATCH. |
path |
To access a specific row and child rows of the dynamic resource. |
payload |
Standard REST payload to pass to POST/PATCH requests. Use either payload or payloadnv. |
payloadnv |
Comma delimited key value pairs to pass to the POST/PATCH request. Use either payload or payloadnv. |
sandbox |
Optional property if the sandbox context is needed. By default it is true, which means the sandbox exists for the resource. The integration always gives the sandbox context by default unless this property is set to "N". |