1Setting Up Workflow
Workflow Basics
You define your transaction workflow using the Process Builder in Oracle Autonomous Integration Cloud (OIC). This topic provides a general introduction to some important OIC terms and lists the high-level steps for setting up workflow for Public Sector Compliance and Regulation transactions. The list of steps includes links to additional specific information for this solution. Use this specific documentation in conjunction with the OIC documentation to learn how to set up workflow for Public Sector Compliance and Regulation.
Workflow is supported for these offerings:
Permits
Planning and Zoning
Business Licenses
To familiarize yourself with the Process Builder in OIC, see your OIC documentation at:https://docs.oracle.com/en/cloud/paas/integration-cloud/user-processes/develop-structured-processes.html.
Important OIC Terms
The OIC object where you set up your workflow tasks is called a process definition.
The following table describes the hierarchy of objects for a process definition. When you set up a type and you choose the appropriate process definition, you need to specify each of these hierarchical objects.
Object |
Description |
---|---|
Space |
Spaces are an organizational tool similar to a folder. Your agency chooses the spaces that make sense for your organization. For example, you can create separate spaces for different categories of s. |
Application |
Applications are functional areas within Spaces. Within an application, you can access a variety of features, including processes (workflow) and integrations. Certain configurations, including integrations and roles, are defined at the application level and shared by all of the application’s process definitions. Therefore, you can simplify the setup process by grouping related process definitions into a single application. |
Version |
When you activate a modified application to make it available for use, you choose a version number to assign. New and modified process definitions can’t be associated with a transaction type until you activate a version of the application that includes your changes.
Caution: If you reuse the same version number when you activate an application, all open process instances using that version are terminated. To prevent this, use a new version number and then update any transaction types that need to use the new version.
|
Process Definition |
A process definition is a specific workflow process. When different types have the same workflow, they can use the same process definition. See Reviewing a Sample Process Definition to walk through an example of a process definition for workflow. |
High-Level Steps for Setting Up Workflow
The OIC documentation provides complete information on setting up workflow, but these are the high level steps, with some notes about product-specific considerations:
Set up a proxy role and user for accessing Oracle Integration Cloud.
See Setting Up a Proxy Role and User for Oracle Integration Cloud.
Create the OIC space and application for your workflow.
Set up your transaction-specific integrations.
See Setting Up the Communications Connector and Setting Up the Transactions Connector.
Create the process definition.
Note: For Public Sector Compliance and Regulation workflow, you must create the process definition using the type Message.Set up swimlanes.
Swimlanes are equivalent to roles in the Public Sector system.
Design your process flow, which includes start and end events, human tasks, system tasks, gateway decision points, and arrows that define the flow through these objects.
Your OIC documentation explains how to create a process flow, but there are additional considerations for Public Sector Compliance and Regulation. See Setting Up Process Definitions for Workflow for these important product-specific tasks:
Setting Up Transaction Data Definitions for a Process
Defining Arguments for the Start Event
Defining Data Associations for the Start Event
Defining Data Associations for Sending Notifications
Defining Data Associations for Sending Transaction Status Updates
Defining Data Associations for Retrieving Transaction Base Data
Defining Data Associations for Retrieving Transaction Field Data
Defining Data Associations for Retrieving Transaction Type Data
Defining Statuses (Outcomes) for Human Tasks
Defining Conditional Logic for Gateways
Use custom properties to add specific information to the human tasks in your workflow.
Activate your application and assign it a version number.
Activating an application makes its new and modified process definitions available to associate with a transaction type. If you reuse the same version number when you activate the application, all open process instances using that version are terminated. To prevent this, use a new version number and update any impacted types so that they reference the new version number.
Note: For applications used for the Planning and Zoning solution, activate the application with the Use Fault Policies option unchecked on the Activation Options page.If this is the first time that the application has been activated, use the Manage Roles functionality in OIC to map swimlanes to roles.
Swimlanes cannot be mapped until the application has been activated. The mapping applies to all process definitions in the application.
Managing Intersystem Connection Disruptions
There is a built-in mechanism for handling temporary unavailability of OIC. An automatic synchronization process runs every hour and scans a database table containing relevant information pertaining to any transaction, such as a transaction in the state of pending submittal. When the process discovers items in the table, it reconnects to OIC to retrieve the process instance for that transaction. After ten attempts, running once each hour, if reconnecting to OIC is not successful, the transaction becomes stale and manual intervention is required.
For example, if a registered user submits an application when OIC happens to be unavailable, that gets set to a state of pending submittal because no process instance can be associated with it due to OIC being unavailable. In that case, the system stores the information for that application in a specific database table, which will be discovered by the synchronization process within an hour. Assuming OIC is available, the synchronization process retrieves the process instance from OIC, associates it with the application, and sets the transaction status to Submitted.
Reviewing a Sample Process Definition
A process definition provides a defined flow for processes such as the transaction lifecycle of a permit. This flow can include system tasks, human tasks, and decision gateways. You define your flow using the Process feature in Oracle Autonomous Integration Cloud (OIC). The Process feature provides a visual design environment to help you create easily understood workflow process definitions.
Let’s look a a sample process definition for a building permit.
This image shows the first half of the sample process, from the time the permit is submitted until it is issued.
![Sample process definition (1 of 2)](images/i-240edad7n-4ca.png)
The following table identifies the types of objects shown in the illustration:
Object |
Description |
---|---|
Swimlanes |
Horizontal bands in the process map represent the roles involved in the process. |
Start and End Events |
All paths through the workflow process must begin at the Start event and finish at the End event. |
Human tasks |
Green boxes with an image of a person represent tasks that are performed by humans. |
System tasks |
Blue boxes with an image of a cloud represent tasks that the system performs. |
Gateways |
White diamonds represent decision points, where the process flow can branch based on criteria you define. |
Arrows |
One-directional arrows define flows through the process. Gateways are the only objects that have multiple exit arrows. The exit arrow with a slash through it represents the default option after a gateway. All other exit arrows contain business logic for defining the conditions when the arrow is used. |
With these definitions in mind, let’s look at the sample process flow:
Start: The process starts when a permit application is submitted, which sends a message to OIC to instantiate the workflow process.
Accept Application: A human performs the task of accepting the application and selecting a task status that represents the task outcome.
Get Permit Fields Data: This system task retrieves permit field data to be used later in the process, when it’s time to determine whether a plan review is required.
Application Decision: Exit arrows from this gateway determine the next step based on the outcome of the Accept Application human task.
If more information is needed, the application acceptance task is reinstantiated. This loop continues until the task has a different outcome.
If the application is rejected, a system task updates the permit status to Denied, then another system task sends the applicant an email notification that the permit was denied, then the process ends.
If the outcome is anything else, the process continues.
Update Status = In Process: This system task updates the permit status to In Process.
Email - Application Accepted: This system task notifies the applicant that the permit was accepted.
Plan Review: Exit arrows from this gateway determine the next step based on the outcome of the Accept Application task and based on the job cost that was retrieved by the Get Permit Fields Data task:
If the Accept Application outcome indicates that a plan review is required, or if the job cost is greater than 10,000, the Update Status = Plan Review system task updates the permit status to Plan Review, then a human completes the Complete Plan Review human task. When the Complete Plan Review is complete, the process continues.
If a plan review is not required, the process continues.
Issue Permit: A human performs the task of issuing the permit and enters a task status that represents the task outcome (whether the permit was issued or rejected).
The following image shows the remainder of the sample workflow, after a human completes the Issue Permit task.
![Sample workflow process (2 of 2)](images/i-240edad7nc24.png)
These steps describe the remainder of the workflow process, after the human task for issuing a permit:
Issue Permit: Exit arrows from this gateway determine the next step based on the outcome of the task for issuing a permit:
If the permit is rejected, the Update Status = Denied This system task updates the permit status to Denied, then the Email - Permit Denied system task notifies the applicant that the permit was denied, then the process ends.
If the outcome is anything else, the process continues.
Update Status = Issued Permit: This system task updates the permit status to Issued Permit.
Email - Permit Issued: This system task notifies the applicant that the permit was issued.
Get Permit Type Data: This system task retrieves permit type information for use in determining whether an inspection is needed.
Inspection: Exit arrows from this gateway determine whether an inspection is needed:
If the permit type includes an inspection group, the Update Status = Inspection system task updates the permit status to Inspection. A human then completes the Approve Final Inspection task and enters the task outcome. The process then continues.
If an inspection is not required, a human performs the Complete Permit task and enters the task outcome. The process then continues.
Update Status = Complete: this system task updates the permit status to Complete.
The process ends.
Setting Up a Proxy Role and User for Oracle Integration Cloud
Oracle Autonomous Integration Cloud (OIC) provides the tools for setting up workflow processes. This topic provides information about using the Security Console to set up a proxy user that the Public Sector system uses to access OIC.
In this procedure, create a user and assign the PSCR Proxy User for OIC (CUSTOM_PSCR_OIC_PROXY_USER) role to that user. You use the Security Console to complete this task. This user is the OIC proxy user that the OIC system uses to connect to Public Sector Compliance and Regulation to exchange data during transaction processing.
For more information about using the Security Console, see: Using the Security Console.
To create the OIC proxy user:
Navigate to the Security Console.
To navigate to the Security Console, you have these options:
In Functional Setup Manager, click the task: Create Process Cloud Service Proxy User.
Click Setup and Maintenance on the Agency Springboard, and on the Fusion Applications home page, select
Click the Users tab.
On the Use Accounts page, click Add User Account.
On the Add User Account page in the User Information section, enter a Last Name and User Name of your choice.
Note: The name given for the proxy user will be displayed on the Status History page of the transaction detail pages, for permits, planning applications, and so on. As such, you may want to use a generic name, such as System, Workflow, or something similar.Enter a Password of your choice and confirm it.
Click Add Role for the Roles grid, and assign this role to your proxy user:
Role Name: PSCR Proxy User for OIC
Role Code: CUSTOM_PSCR_OIC_PROXY_USER
Click Save and Close.
Setting Up the Communications Connector
The communications connector enables OIC to send data to the communications center in the Oracle Public Sector Compliance and Regulation system using a POST operation. This connector is used when a workflow process definition includes a communication task, such as sending a permit applicant an email when the permit status changes.
Oracle provides a Solution Package with sample integration configurations. You can clone these samples and use them as starting points for your own connectors. The instructions in this procedure explain how to set up the communications connector from scratch.
The following procedure explains how to set up the communications connector with the specific integration information that is required by the Public Sector system. For general instructions related to setting up integrations in OIC, refer to your OIC documentation at https://docs.oracle.com/en/cloud/paas/integration-cloud/user-processes/integrate-applications-and-services.html
To set up the communication connector:
Go to My Oracle Support, access Doc ID 2449735.1, Public Sector Compliance and Regulation: JSON Files for Transaction Integration, and download the following files that you will use later in this procedure:
RequestCommunications.json
ResponseCommunications.json
Access the main console in OIC.
In the list of OIC applications, click the application with your transaction workflow.
Click the Integrations option in the left frame.
Click the Create button, then in the pop-up menu under the Create button, select
In the Create REST Connector window, enter the following:
Page Element
Description
Name
Enter a descriptive name such as CommunicationsConnector.
Note: The name CommunicationsConnector is suggested, however, you can choose your own name if needed.Base URL
Enter the URL for your Oracle Public Sector Cloud REST API resources. The URL follows this pattern, where ServerName is the server name for your instance of the application:
https://ServerName/fscmRestApi/resources/11.13.18.05
Open Immediately
Select this check box if it is not already selected.
Click Create.
The Rest Connector Editor opens.
To set up security for this integration, click the Edit link for the Configuration section.
Note: If you prefer to set up security when you activate the workflow application, you can skip the security-related steps in this procedure and skip ahead to step 13. Setting up security now simplifies the application activation steps.Click the Security tab.
In the Security Type field, select APP Id - Basic Authentication.
Complete these additional fields that appear after you select the Security Type:
Page Element
Description
Keystore Credential
If you previously created a keystore credential, select it. Otherwise, leave this field set to [New Key] so that the system will create the keystore credential when you apply your changes.
Key Name
If you selected [New Key] as the keystore credential, enter the name to give to the new keystore.
If you selected an existing keystore credential, this field is read-only and displays the key name.
Username
Enter the user name for the process cloud proxy user that you previously created.
If you’re using an existing keystore credential, that credential supplies a default username.
Password
Enter the password for the process cloud proxy user that you previously created.
If you’re using an existing keystore credential, that credential supplies a default password.
Click Apply to save the security information and close the Configuration section.
In the Resources section of the Rest Connector Editor, click Add.
Expand the new Resource section that appears, and enter the following values:
Field
Value
Name
OutboundCommunications
Path
publicSectorCommunicationRequests
When added to the base URL, this completes the path to the communications-related REST APIs.
In the Operations section, click the Add button and then select POST operation from the drop-down menu.
Click the new POST operation.
Enter Trigger transaction communications in the Documentation field.
You can leave the default values in the other fields, including leaving the Path field blank.
Click Request
Click the + icon next to the Body field to open the Import Business Object from JSON window.
Enter RequestCommunications in the Name field.
Click Schema.
Click the Import from File icon next to the Schema button.
Locate and upload the RequestCommunications.json file that you downloaded from My Oracle Support.
The imported JSON code appears in the Import Business Object from JSON window.
Click the Import button at the bottom of the window to save the code and close the window.
Ensure that the following values now appear for the POST operation request:
Page Element
Value
Body
BusinessData.RequestCommunications
Media Type
Custom
Media Type details
application/vnd.oracle.adf.resourceitem+json
Click Response.
Click the + icon next to the Body field to open the Import Business Object from JSON window.
Enter ResponseCommunications in the Name field.
Click Schema.
Click the Import from File icon next to the Schema button.
Locate and upload the ResponseCommunications.json file that you downloaded from My Oracle Support.
The imported JSON code appears in the Import Business Object from JSON window.
Click the Import button at the bottom of the window to save the code and close the window.
Ensure that the following values appear for the POST operation response:
Page Element
Value to Enter
Body
BusinessData.ResponseCommunications
Media Type
application/JSON
Click Apply.
Click Save.
Setting Up the Transactions Connector
The transactions connector enables OIC to exchange transaction-related information with the Public Sector Compliance and Regulation system.
Oracle provides a Solution Package with sample integration configurations. You can clone these samples and use them as starting points for your own connectors. The instructions in this procedure explain how to set up the transactions connector from scratch.
The procedures that follow are for entering the specific information that is required by the Public Sector Compliance and Regulation system. For general instructions related to setting up integrations in OIC, refer to your OIC documentation at https://docs.oracle.com/en/cloud/paas/integration-cloud/user-processes/integrate-applications-and-services.html
Procedure Overview for Setting Up the Transactions Connector
Setting up the Transactions Connector comprises multiple procedures with multiple steps. The following set of steps outline the high-level set of procedures involved with this task. Each item in the following list is explained in more detail in the following sections, in the listed sequence.
Download Required JSON Files for Workflow Integration Configuration
Create the Transactions Connector
Add the Transaction Resource
Add the PATCH Operation for Transaction Statuses
Add the GET Operation for Transaction Base Data
Add the GET Operation for Transaction Fields Data
Add the GET Operation for Transaction Data
Add the GET Operation for Transaction Assignee
Add the Transaction Type Resource
Add the GET Operation for Transaction Type Data
Step 1: Download Required JSON Files for Workflow Integration Configuration
For creating integrations from scratch, Oracle provides a set of JSON files for defining the integration between OIC and the Public Sector Compliance and Regulation system. Download all of the files first so that you can access them easily while completing the procedures documented in this topic.
To download the required JSON:
Sign on to My Oracle Support.
Access Doc ID 2449735.1, Public Sector Compliance and Regulation: JSON Files for Transaction Integration.
Download the following files to a local folder:
RequestTransStatusUpdate.json
ResponseTransStatusUpdate.json
ResponseTransBase.json
ResponseTransFields.json
ResponseTransData.json
ResponseTransAssignee.json
ResponseTransType.json
Step 2: Creating the Transaction Connector
To set up the transactions connector:
Access the main console in OIC.
In the list of OIC applications, click the application for your workflow process.
Click the Integrations option in the left frame.
Click the Create button, then in the pop-up menu under the Create button, select
In the Create REST Connector window, enter the following:
Page Element
Description
Name
Enter a descriptive name, such as TransactionConnector.
Note: The name TransactionConnector is suggested, however, you can choose your own name if needed. This documentation refers to TransactionConnector.Base URL
Enter the URL for your Oracle Public Sector Cloud REST API resources. The URL follows this pattern, where ServerName is the server name for your instance of the application:
https://ServerName/fscmRestApi/resources/11.13.18.05
Open Immediately
Select this check box if it is not already selected.
Click Create.
The Rest Connector Editor opens.
If you want to set up security for this integration now, click the Edit link for the Configuration section.
Note: If you prefer to set up security later when you activate the workflow application, you can skip the security-related steps in this procedure. Setting up security now simplifies the application activation steps.Click the Security tab.
In the Security Type field, select APP Id - Basic Authentication.
Complete these additional fields that appear after you select the Security Type:
Page Element
Description
Keystore Credential
If you previously created a keystore credential, select it. Otherwise, leave this field set to [New Key] so that the system will create the keystore credential when you apply your changes.
Key Name
If you selected [New Key] as the keystore credential, enter the name to give to the new keystore.
If you selected an existing keystore credential, this field is read-only and displays the key name.
Username
Enter the user name for the process cloud proxy user that you previously created.
If you’re using an existing keystore credential, that credential supplies a default username.
Password
Enter the password for the process cloud proxy user that you previously created.
If you’re using an existing keystore credential, that credential supplies a default password.
Click Apply to save the security information and close the Configuration section.
Click Save
Step 3: Add the Transactions Resource
Access the main console in OIC.
In the list of OIC applications, click the application for your workflow process.
Click the Integrations option in the left frame.
Click the TransactionConnector integration.
In the Resources section of the Rest Connector Editor, click Add.
Expand the new Resource section that appears, and enter TransactionResource in the Name field.
Step 4: Add the PATCH Operation for Transaction Statuses
Workflow in OIC uses the PATCH operation to update the status of a transaction.
To set up the PATCH operation:
In the Operations section of TransactionResource, click the Add button and then select PATCH operation from the drop-down menu.
Click the new PATCH operation.
Enter the following information:
Page Element
Value
Name
patchTransactionStatus
Path
{transResource}/{transRecordKey}
Although you can choose different names for the resource name and record key parameters, this procedure assumes that you use the given values.
Documentation
Update transaction status.
Click Request
Click the + icon next to the Body field to open the Import Business Object from JSON window.
Enter RequestTransStatusUpdate in the Name field.
Click Schema.
Click the Import from File icon next to the Schema button.
Locate and upload the RequestTransStatusUpdate.json file that you downloaded from My Oracle Support.
The imported JSON code appears in the Import Business Object from JSON window.
Click the Import button at the bottom of the window to save the code and close the window.
Ensure that the following values now appear for the PATCH operation request:
Page Element
Value to Enter
Body
BusinessData.RequestTransStatusUpdate
Media Type
Custom
Media Type details
application/vnd.oracle.adf.resourceitem+json
In each row of the Parameters list, click the Enter a description text and enter a description.
These are example descriptions:
Parameter
Description
transResource
Transaction Resource Name
transRecordKey
Transaction Record Key
Click Response.
Click the + icon next to the Body field to open the Import Business Object from JSON window.
Enter ResponseTransStatusUpdate in the Name field.
Click Schema.
Click the Import from File icon next to the Schema button.
Locate and upload the ResponseTransStatusUpdate.json file that you downloaded from My Oracle Support.
The imported JSON code appears in the Import Business Object from JSON window.
Click the Import button at the bottom of the window to save the code and close the window.
Ensure that the following values appear for the PATCH operation response:
Field
Value
Body
BusinessData.ResponseTransStatusUpdate
Media Type
application/JSON
Click Apply.
Click Save.
Step 5: Add the GET Operation for Transaction Base Data
The getTransactionBaseData operation gets general transaction data that is found in all transactions, such as the permit type, the permit status, and the permit applicant for a permit transaction.
Expand the TransactionResource resource.
In the Operations section, click the Add button and then select GET operation from the drop-down menu.
Click the new GET operation.
Enter the following information:
Field
Value
Name
getTransactionBaseData
Path
{transResource}/{transRecordKey}
Although you can choose different names for the resource name and record key parameters, this procedure assumes that you use the given values.
Description
Get base transaction data, such as applicant information
Click Request
In each row of the Parameters list, click the Enter a description text and enter a description.
These are example descriptions:
Parameter
Description
transResource
Transaction Resource Name
transRecordKey
Transaction Record Key
Click Response.
Click the + icon next to the Body field to open the Import Business Object from JSON window.
Enter ResponseTransBase in the Name field.
Click Schema.
Click the Import from File icon next to the Schema button.
Locate and upload the ResponseTransBase.json file that you downloaded from My Oracle Support.
The imported JSON code appears in the Import Business Object from JSON window.
Click the Import button at the bottom of the window to save the code and close the window.
Ensure that the following values appear for the GET operation response:
Page Element
Value to Enter
Body
BusinessData.ResponseTransBase
Media Type
application/JSON
Click Apply.
Step 6: Add the GET Operation for Transaction Fields Data
The getTransactionFieldsData gets field data from the application intake form configured using the Intake Form Designer.
In the Operations section of the Transactions Resource, click the Add button and then select GET operation from the drop-down menu.
Click the new GET operation.
The new GET operation has the default name of GetTransactionResources.
Enter the following information:
Field
Value
Name
getTransactionFieldsData
Path
{transResource}/{transRecordKey}/child/FieldGroups
Although you can choose different names for the resource name and record key parameters, this procedure assumes that you use the given values.
Description
Get specific transaction data, such as job cost.
Click Request.
In each row of the Parameters list, click the Enter a description text and enter a description.
These are example descriptions:
Parameter
Description
transResource
Transaction Resource Name
transRecordKey
Transaction Record Key
Click Response.
Click the + icon next to the Body field to open the Import Business Object from JSON window.
Enter ResponseTransFields in the Name field.
Click Schema.
Click the Import from File icon next to the Schema button.
Locate and upload the ResponseTransFields.json file that you downloaded from My Oracle Support.
The imported JSON code appears in the Import Business Object from JSON window.
Click the Import button at the bottom of the window to save the code and close the window.
Ensure that the following values appear for the GET operation response:
Page Element
Value to Enter
Body
BusinessData.ResponseTransFields
Media Type
application/JSON
Click Apply.
Click Save.
Step 7: Add the GET Operation for Transaction Data
The getTransactionData combines getTransactionBaseData and getTransactionFieldsData into a single operation, which you can use instead of using getTransactionBaseData and getTransactionFieldsData separately.
In the Operations section, click the Add button and then select GET operation from the drop-down menu.
Click the new GET operation.
The new GET operation has the default name of GetTransactionResources.
Enter the following information:
Field
Value
Name
getTransactionData
Path
{transResource}/{transRecordKey}
Although you can choose different names for the resource name and record key parameters, this procedure assumes that you use the given values.
Description
Combines getTransactionBaseData and getTransactionFieldsData into a single operation.
Click Request.
In each row of the Parameters list, click the Enter a description text and enter a description.
These are example descriptions:
Parameter
Description
transResource
Transaction Resource Name
transRecordKey
Transaction Record Key
Click Response.
Click the + icon next to the Body field to open the Import Business Object from JSON window.
Enter ResponseTransactionData in the Name field.
Click Schema.
Click the Import from File icon next to the Schema button.
Locate and upload the ResponseTransactionData.json file that you downloaded from My Oracle Support.
The imported JSON code appears in the Import Business Object from JSON window.
Click the Import button at the bottom of the window to save the code and close the window.
Ensure that the following values appear for the GET operation response:
Page Element
Value to Enter
Body
BusinessData.ResponseTransactionData
Media Type
application/JSON
Click Apply.
Click Save.
Step 8: Add the GET Operation for Transaction Assignee
In the Operations section, click the Add button and then select GET operation from the drop-down menu.
Click the new GET operation.
The new GET operation has the default name of GetTransactionResources.
Enter the following information:
Field
Value
Name
getTransactionAssignee
Path
publicSectorTransactionLatestAssignees/{transRecordKey}
Although you can choose different names for the resource name and record key parameters, this procedure assumes that you use the given values.
Description
Get specific transaction data, such as job cost.
Click Request.
In each row of the Parameters list, click the Enter a description text and enter a description.
These are example descriptions:
Parameter
Description
transRecordKey
Transaction Record Key
Click Response.
Click the + icon next to the Body field to open the Import Business Object from JSON window.
Enter ResponseTransactionFields in the Name field.
Click Schema.
Click the Import from File icon next to the Schema button.
Locate and upload the ResponseTransAssignee.json file that you downloaded from My Oracle Support.
The imported JSON code appears in the Import Business Object from JSON window.
Click the Import button at the bottom of the window to save the code and close the window.
Ensure that the following values appear for the GET operation response:
Page Element
Value to Enter
Body
BusinessData.ResponseTransAssignee
Media Type
application/JSON
Click Apply.
Click Save.
Step 9: Add the Transaction Type Resource
Access the main console in OIC.
In the list of OIC applications, click the application for your workflow process.
Click the Integrations option in the left frame.
Click the TransactionsConnector integration.
In the header of the Resources section, click Add to create a new transaction type resource.
Expand the new Resource section that appears, and enter the following information:
Field
Value
Name
TransactionTypeResource
Path
publicSectorRecordTypes
Step 10: Add the GET Operation for Transaction Type Data
The GetTransactionTypeData operation gets data that is associated with the transaction type definition rather than with an individual transaction. For example, this operation can get the overall fee structure for a permit definition, because the fee structure is associated with the permit type.
To set up the GET operations for transaction type data:
In the Operations section of the Transaction Type Resource, click the Add button and then select GET operation from the drop-down menu.
Click the new GET operation.
Enter the following information:
Page Element
Value
Name
getTransactionTypeData
Path
{transResource}
Documentation
Get transaction type setup data.
Click Request
In the Parameters list, click the Enter a description text and enter a description.
Here is an example description:
Parameter
Description
transResource
Transaction Resource Name
Click Response.
Click the + icon next to the Body field to open the Import Business Object from JSON window.
Enter ResponseTransTypeData in the Name field.
Click Schema.
Click the Import from File icon next to the Schema button.
Locate and upload the ResponseTransType.json file that you downloaded from My Oracle Support.
The imported JSON code appears in the Import Business Object from JSON window.
Click the Import button at the bottom of the window to save the code and close the window.
Ensure that the following values appear for the GET operation response:
Page Element
Value to Enter
Body
BusinessData.ResponseTransTypeData
Media Type
application/JSON
Click Apply.
Click Save.
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.
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
Leave Open Immediately selected and click Create.
Click Edit to display the Configuration section.
On the General tab, make sure the base URL is correct.
Select the Security tab, and enter the proxy user created to access the Public Sector Compliance and Regulation data.
Page Element
Value
Security Type
APP Id – Basic Authentication
Username and Password
The proxy user you set up for OIC and PSCR integration.
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:
This example illustrates adding the JSON payload for the Sandbox Connector. Details are in the surrounding text.
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.
This example illustrates a collapsed process definition node. Details are in the surrounding text.
This example illustrates an expanded process definition node. Details are in the surrounding text.
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:
This example illustrates how to map data associations for process definitions. Details are in the surrounding text.
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 OIC 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". |
Setting Up Process Definitions for Workflow
Workflow manages status updates throughout the transaction lifecycle and is an essential part of your setup. This topic provides information for creating your workflow process definitions.
Setting Up Data Objects for a Process
Data objects provide a structure for storing data sent from the Public Sector Compliance and Regulation system. Every process definition that you create needs the same data objects, including:
Simple string data definitions to store identifying information about the transaction and transaction type.
Business object data definitions to store transaction base data, field data, and transaction type data.
The data definition for fields includes all possible fields that can be added to an intake form, even though the transaction may use only a subset of fields that are appropriate for the type of transaction. Any fields that are not part of a specific transaction type remain blank when the workflow process retrieves the field data.
You must set up your data objects before you continue to this topic’s additional procedures for defining data associations.
To set up data objects for a process definition:
Access the process definition in OIC.
Click Data Objects.
Set up the data definition for transaction base data:
In the Data Objects window, click Add.
In the Create Process Data Object window, enter the following information:
Page Element
Value
Name
transactionBaseData
Data Type
Business
The drop-down list for data types
BusinessData.ResponseTransBase
Click Create to create the data definition and return to the Data Objects window.
Set up the data definition for transaction field data:
Click Add.
Enter the following information:
Page Element
Value
Name
transactionFieldsData
Data Type
Business
The drop-down list for data types
BusinessData.ResponseTransFields
Click Create.
Set up the data definition for transaction type data:
Click Add.
Enter the following information:
Page Element
Value
Name
transactionTypeData
Data Type
Business
The drop-down list for data types
BusinessData.ResponseTransType
Click Create.
Click Close to close the Data Objects window.
Click Save.
Creating a Data Object to Store Start Event Arguments
In the next task you will define the start arguments for the Start event. In this procedure, you create the structure to store the arguments.
This procedure involves:
Creating a business type using the business object option.
Creating a data object and associating it with the business object.
To create the data object for start event arguments:
Open the process definition.
Select Business Types from the left panel.
Note: Notice the other business types created automatically when importing the downloaded JSON, such as ResponseTransactionData.Click Edit in the header, which causes the Create button to appear.
Click Create, and select New Business Object.
On the Create Business Object dialog box, enter the business object name, such as InitTransaction, and select the Parent Module as BusinessData.
Click Next.
Use the Add Attribute button to add these string data types to the business object.
Attribute Name
Data Type
transactionKey
String
transactionType
String
externalBaseURL
String
resourceName
String
transactionOwner
String
transactionId
String
classification
String
subclassification
String
Click Finish.
Return to your process definition diagram.
Click the Data Objects button.
Click Add.
On the Create Process Data Object dialog box, make these changes:
Field
Value
Name
transaction
Data Type
Business
drop-down list
BusinessData.InitTransaction
Click Create.
This example illustrates the expanded transaction business data object, with the required string data within it.
![Creating a business object to store process definition data](images/i-7c7a61f9n-5563.png)
Defining Arguments for the Start Event
When a transaction, such as a permit intake application, is submitted, the software instantiates that transaction’s workflow process by passing parameters, such as the transaction ID, to OIC. The Start event in your process diagram must have arguments defined for these parameters.
To set up the arguments for the start event:
Select the Start event in the process definition.
Click the Start event, and select Open Properties.
The default view is the General section of the Implementation Properties.
In the How do you want to implement it? section, select Define Interface as the Type.
Click the pencil icon next to the Type field to open the Configure window.
Enter an operation name, such as start.
Add the following rows to the Arguments Definition.
Use the Add button to add these strings using the values in this table, where each row represents a separate argument you need to create:
Name
Type
TransactionKey
string
TransactionType
string
ExternalBaseURL
string
ResourceName
string
TransactionOwner
string
TransactionId
string
Classification
string
Subclassification
string
Note: Arguments added to the Start event must be named exactly as documented.Note: You need to complete the output data association if you want the argument values stored in a Data Object.Click OK.
Close the properties panel and click Save.
Defining Data Associations for the Start Event
The data associations for the Start event capture identifying information about the transaction for initiating the process instance.
In this task, you map the arguments for the Start event to the data object values you entered for the transaction object.
To set up the data associations:
Open the process definition and select the Start event.
Click the Data Association button.
Set up the following data associations, mapping the Start event arguments to the appropriate attributes in transaction business object.
Source Data
(Left side of the map)
Target Data
(Right side of the map)
Description
TransactionKey
transaction.transactionKey
The transaction ID.
TransactionType
transaction.transactionType
The transaction type ID.
ExternalBaseURL
transaction.externalBaseURL
The URL for the Public Sector Compliance and Regulation system.
ResourceName
transaction.resourceName
The name of the REST API resource.
TransactionOwner
transaction.transactionOwner
The owner of the transaction.
TransactionId
transaction.transactionId
The transaction ID.
Classification
transaction.classification
The classification of the transaction.
Subclassification
transaction.subClassification
The subclassification of the transaction.
This example illustrates mapping the Start event arguments to the associated data attributes in the transaction business object.
Click Apply.
Click Save.
Defining Data Associations for Sending Notifications
The data associations for a notification task define the information that the task sends to the public sector communications center.
For more information about the communications center, see Setting Up Communication Templates.
To set up the data associations:
Access the process definition and select the system task.
Click the Data Association button.
Set up the following input data associations:
Source Data
(Left side of the map)
Target Data
(Right side of the map)
Description
[event name]
For example, "LNP_WORKFLOW_001"
body.eventCode
The event as defined in the Communications Center in the public sector system.
The source data string must be in quotation marks, and it must exactly match the identifier of an event.
Oracle delivers these communication events, <Offering>_WORKFLOW_001 through <Offering>_WORKFLOW_005. Where “Offering” refers to your offering code, such as LNP for Permits or PNZ for Planning and Zoning.
[template name]
For example, "Application_Accepted"
body.templateCode
The identifier for the template to be used for the email.
The source data string must be in quotation marks, and it must exactly match the name of a template in the transaction application.
"LnpRecordKey"
body.recordFirstKeyName
The name of the key field.
transaction.transactionKey
body.recordFirstKeyValue
The transaction ID.
true or false
body.email
This Boolean field indicates whether the notification is sent as an email.
Enter true only if the template is an email template.
true or false
body.notification
This Boolean field indicates whether the notification is sent as an in-product notification.
. Enter true only if the template is an in-product notification template.
Caution: Templates are associated with either email or in-system notifications. Be sure to set up the body.email and body.notification values properly. Exactly one of the values must be true. If you want to send both types of notifications, you need to create two notification tasks.Click Apply.
Click Save.
Defining Data Associations for Sending Status Updates
The data associations for a status update task define the information that the task sends to the Public Sector Compliance and Regulation system.
To set up the data associations:
Access the process definition and select the system task that updates the transaction status.
Click the Data Association button.
Set up the following input data associations:
Source Data
(Left side of the map)
Target Data
(Right side of the map)
Description
transaction.resourceName
resourceName
The unique system identifier for the transaction type.
transaction.transactionKey
transactionKey
The transaction ID
[new transaction status]
For example: "Accepted"
body.status
The status to be assigned to the transaction.
The source data string must be in quotation marks, and it must exactly match one of the valid statuses for the transaction application.
Click Apply.
Click Save.
Defining Data Associations for Retrieving Transaction Base Data
The data associations for a task that retrieves transaction base data provides a structure for storing the retrieved data. In this task you create both input and output data associations.
To set up the data associations:
Access the process definition, and select the system task that retrieves transaction base data.
Click the Data Association button.
Set up the following input data associations:
Source Data
(Left side of the map)
Target Data
(Right side of the map)
Description
transaction.resourceName
Resource
The unique system identifier for the transaction type.
transaction.transactionKey
TransactionKey
The transaction ID
Click Output.
Set up the following output data associations:
Source Data
(Left side of the map)
Target Data
(Right side of the map)
Description
body
BaseData
This business object contains all of thebase data.
Mapping individual fields would be much more complex and is not necessary.
Click Apply.
Click Save.
Defining Data Associations for Retrieving Transaction Field Data
The data associations for a task that retrieves transaction field data provides a structure for storing the retrieved data. In this task you create both input and output data associations.
To set up the data associations:
Access the process definition, and select the system task that retrieves transaction field data.
Click the Data Association button.
Set up the following input data associations:
Source Data
(Left side of the map)
Target Data
(Right side of the map)
Description
transaction.resourceName
transactionResource
The unique system identifier for the transaction type.
transaction.transactionKey
TransactionKey
The transaction ID.
Click Output.
Set up the following output data associations:
Source Data
(Left side of the map)
Target Data
(Right side of the map)
Description
body
transactionFieldsData
This business object contains all of the transaction fields. This includes all fields that can be included on the application intake form, whether or not the field exists for a specific transaction.
Individual fields are nested within the items object. You can’t expand the items object on this page, but they are available in the expression editor that you use when creating business logic based on transaction data.
Mapping individual fields would be much more complex and is not necessary.
Click Apply.
Click Save.
Defining Data Associations for Retrieving Transaction Type Data
The data associations for a task that retrieves transaction type data provides a structure for storing the retrieved data. In this task you create both input and output data associations.
To set up the data associations:
Access the process definition, and select the system task that retrieves transaction type data.
Click the Data Association button.
Set up the following input data associations:
Source Data
(Left side of the map)
Target Data
(Right side of the map)
Description
transaction.resourceName
transactionResource
The unique system identifier for the transaction type.
Click Output.
Set up the following output data associations:
Source Data
(Left side of the map)
Target Data
(Right side of the map)
Description
body
transactionTypeData
This business object contains all transaction type fields.
Click Apply.
Click Save.
Defining Statuses (Outcomes) for Human Tasks
The Action property for a human task lists the possible outcomes of the task. The actions you define appear as values in the Task Status drop-down list box on the Workflow page where agency staff manages workflow tasks. When the task status is updated on the Workflow page, OIC recognizes it as the task outcome and continues to the next step or gateway.
To define status values representing the outcomes of human tasks:
Access the process definition and select the human task.
Open the task properties.
In the Action field, enter a comma-delimited list of status values.
Do not put a space before or after the comma. For example, if the status are Accept, Reject, and More Information, enter Accept,Reject,More Information in the Action field.
Close the properties window and save.
Defining Conditional Logic for Gateways
In a process map, gateways represent decision points where there is a branch in the process flow. The logic for taking different paths after the gateway is associated with the arrows to the possible subsequent tasks.
An arrow that represents a default branch does not require any logic.
For all other arrows, you need to set up the conditions under which the branch is used. To do this:
Access the process definition and select the arrow.
Click the pencil icon for the arrow to open the arrow properties.
Select the Conditional Flow check box.
This check box is selected for all arrows other than the default arrow after a gateway.
Click the pencil icon for the Condition field.
Use the Expression Editor window to specify the conditions for using this branch.
The Data Objects tab provides access to the data elements that you can evaluate. Transaction field data (the data from the intake form) is nested within the items element under TransactionFieldsData.
In expressions that look for an exact match, take extra care with the spelling, capitalization, and punctuation of values that the expression evaluates.
Select the gateway and open the gateway properties.
Use the Order property to specify the order in which the previous task’s outcomes are evaluated for purposes of determining which arrow to follow.
Configuring a Planning and Zoning Human Task to Reference the Assigned Planner Value
If you want to assign the user to a human task, you need to have first setup the Transaction Connector to use the getTransactionAssignee operation.
For more information on setting up the Transaction Connector, see Setting Up the Transactions Connector.
To associate the transaction assignee data to your workflow process:
When configuring the workflow process data object, create a data object to store the output of the service call to getTransactionAssignee.
Locate the first human task in the process after the service call (Start event), and open the Data Association interface.
On the Input Data Association, map the assignee data object to execData.customAttributes.customAttributeString1.
For subsequent human task to which you want to reference the assigned planner, set the Assignee(s) value in the General Properties to customAttributes.customAttributeString1.
Open the properties for the human task.
Select Implementation > General.
Click the Edit icon for the Assignee(s) field.
Select Names and Expressions in the Build a list of participants using list.
Click Add for the List Assignees edit box.,
Select Add User.
Click in the Data Type column, and select By Expression.
Click the fx button in the Value column, and select customAttributes.customAttributeString1.
Click OK.
This example illustrates the settings on the List assignees who receive the task window.
Click Save.
Implementing the Expiration Feature
If you are implementing the expiration feature for Permits or Planning and Zoning, you need to add these system tasks to the workflow process definition in Oracle Integration Cloud:
System Task |
Description |
---|---|
Accepted |
Updates the transaction status to Accepted. This task should be placed early in the process flow. |
Completed |
Updates the transaction status to Completed or Certified. This task should be placed at the end of the process flow. |
Using Custom Properties
When you set up workflow, a variety of custom properties are available for implementing various features. This topic describes how use the custom properties.
These custom properties are available for workflow and are described in more detail below:
Property |
Usage |
Values |
---|---|---|
PSC_LIST_ORDER |
Use this property to set the order for human tasks when there are multiple possible paths through the process definition. The order does not affect the workflow process, but it allows users to see the possible future workflow tasks in a logical order. |
Integers For example: PSC_LIST_ORDER: 2 |
PSC_FINAL_ACTIVITY |
Use this property to identify a human task that is not allowed to progress when the transaction has a condition that applies the Prevent Issue or Final business rule. In particular, use this property to identify the final human task in the process definition. See Setting Up Conditions and Applying Conditions to Applications. |
Yes identifies the final activity. A blank value or a No value means that the task is not the final activity. For example: PSC_FINAL_ACTIVITY: Yes |
PSC_ACTIVITY_TYPE |
Use this property to identify the final inspection task in the process. Setting this property is necessary to support the transaction business logic that auto-advances the inspection task when the last inspection is closed. |
Inspection is the only value with related business logic.
Leave this property blank for other types of activities. |
PSC_AUTO_UPDATE_ACTION |
Use this property to identify the action to take when auto-advancing the final inspection task in a process. Setting this property is necessary to support the transaction business logic that auto-advances the inspection task when the last inspection is closed.
Note: Security roles related to the Mobile Inspector app and the Plan Reviewer should be included in the task swimlane mapping.
|
The exact action name as specified in the Action property for the human task. Take extra care with the spelling, capitalization, and punctuation of the action name. For example: PSC_AUTO_UPDATE_ACTION: Approve |
PSC_UNRESTRICTED_ACTIONS |
Identifies actions that can be taken for the task even if there is logic preventing the task from advancing. Use this property when the task includes possible outcomes that return to a previous task rather than advancing. For example, if the final inspection can be advanced with an action of “Approve” or returned with an action of “Needs More Information,” then use the PSC_UNRESTRICTED_ACTIONS property to make “Needs More Information” an unrestricted action. This allows users to take the “Needs More Information” action, even though the logic that prevents the final inspection task from advancing disallows other actions. Currently, the PSC_UNRESTRICTED_ACTIONS property is applicable only for the Inspection action, as identified by the PSC_ACTIVITY_TYPE. |
When there are multiple unrestricted actions, separate the actions with commas but no spaces. This is the same format used in the Actions property where you define all of the available actions for a human task. For example: PSC_UNRESTRICTED_ACTIONS: Needs more Info, Proceed, OK |
Making Custom Properties Available in a Process Definition
Before you can use a custom property, you need to add the property to the process definition. You must do this for each of your process definitions.
To add a custom property to a process definition:
Access the process definition and click the # (Custom Properties) toolbar icon.
Enter the following values in the Property Name and Description fields in the Custom Properties list:
Note: You must use the exact property names given in this procedure. You can, however, alter the descriptions.Property Name
Description
PSC_LIST_ORDER
Human tasks display order
PSC_FINAL_ACTIVITY
Identify the final human task
PSC_ACTIVITY_TYPE
Identify the type of activity such as inspection
PSC_AUTO_UPDATE_ACTION
Identify the action to take when auto-advancing
Click OK.
Click Save.
PSC_LIST_ORDER Property
The Workflow page for a permit includes an option to view a list of all past, present, and not started human tasks for the permit. The list displays past and present tasks in chronological order. However, the chronology for tasks that haven’t been started is not necessarily fixed. The branching logic in a process means that some tasks might be omitted or might occur in a different order depending on permit data or on the outcome of previous tasks.
To control the order in which not started human tasks appear, use the PSC_LIST_ORDER custom property. On the Workflow page’s list view, tasks that have not yet started are listed in the order you specify. If multiple not started tasks have the same number, they appear in the list in random order.
To assign order numbers to human tasks:
Analyze all human tasks in the process and decide on the appropriate order.
Tasks appear in ascending numerical order. You assign order numbers one task at a time, so if you later decide to change the order, you have to update each affected task individually.
Access the process definition.
Select a human task.
Open the task properties.
Select the Business Properties icon in the icon bar, then select Custom Properties from the list of options that are associated with that icon.
Enter a number in the PSC_LIST_ORDER custom property.
Close the Properties window and save.
Repeat the previous steps for all human tasks in the process definition.
Click Save.
PSC_FINAL_ACTIVITY Property
Human tasks that you identify as a final activity cannot advance when a permit has a condition that applies the Prevent Issue or Final business rule.
To identify the final human task using the PSC_FINAL_ACTIVITY property:
Access the process definition.
Select the final human task.
Open the task properties.
Select the Business Properties icon in the icon bar, then select Custom Properties from the list of options that are associated with that icon.
Enter Yes in the PSC_FINAL_ACTIVITY custom property.
To remove a Yes value from this property, set the value to No or clear the value and leave it blank.
Close the Properties window and save.
Click Save.
PSC_ACTIVITY_TYPE and PSC_AUTO_UPDATE_ACTION Properties
Permit processing includes logic to automatically progress past the final inspection step in the process definition when permit inspections are complete. To enable this functionality, you must identify the final inspection task in the process definition using the PSC_ACTIVITY_TYPE custom property. Further, you must identify the workflow action to apply to that task using the PSC_AUTO_UPDATE_ACTION custom property.
To set up custom properties for auto-advancing an inspection task:
Access the process definition.
Select the human task that represents final inspections.
Open the task properties.
Select the Business Properties icon in the icon bar, then select Custom Properties from the list of options that are associated with that icon.
Enter Inspection in the PSC_ACTIVITY_TYPE custom property.
Enter the desired action in the PSC_AUTO_UPDATE_ACTION custom property.
The action you enter is the action to be taken when the task is successfully complete—that is, when the permit passes its final inspection. Take care to use the correct spelling, capitalization, and punctuation for the action name.
Close the Properties window and save.
Click Save.
Mapping Workflow Swimlanes to Roles
This topic describes how to assign security roles to the swimlanes in your workflow process definition.
In workflow process definitions, swimlanes represent roles. After the OIC application containing the process definition is activated, use the Manage Roles functionality in OIC to map the swimlanes to roles. The mapping applies to all process definitions in the OIC application.
A swimlane is typically associated with security roles, and it can be associated with multiple roles if needed. It can also be associated with one or more individual users if that approach is more applicable. A swimlane determines who is responsible for carrying out a task.
For example, if a swimlane is for plan review, you would add the PSC Plan Reviewer role to that swimlane. Likewise, if another swimlane is for inspecting, you would add all the roles that apply to that swimlane, such as PSC Building Inspector and any roles related to the Mobile Inspector app.
To map swimlanes to roles:
Access the My Tasks area of Oracle Autonomous Integration Cloud.
Click My Tasks in the left navigation menu, and click Workspace in the My Tasks header.
Click Administration in the left navigation menu.
If the Manage Roles page does not appear by default, click Manage Roles in the left navigation menu.
The Manage Roles page lists process roles using the format [application].[swimlane].
Search for your application to filter the list.
The Process Owner and Process Reviewer roles are part of all applications. Other swimlanes in the list are ones that you created in your process definitions.
Add the delivered role PSCR Submitter Group to the swimlane that contains the Start event for your process model:
Select the swimlane that contains the Start task in your process definitions.
In the delivered Solution Packages that Oracle provides, this swimlane is labeled Applicant. This swimlane applies to the user submitting a transaction, such as a permit application.
In the Assign Roles list for the selected swimlane, click Add Member.
In the dialog box for adding members, search by Groups for PSCR Submitter Group.
A group in OIC is equivalent to a role in the Public Sector Compliance and Regulation system.
In the search results, select PSCR Submitter Group and then click OK to assign the role to the swimlane and return to the list of swimlanes.
Click Save.
Monitoring Workflow Transactions
This topic describes how to use the Inconsistent Instances page to resolve discrepancies between the Public Sector Compliance and Regulation system and the Oracle Integration Cloud instance (OIC).
Working with Workflow Transaction Logs
During normal transaction processing, it’s possible that either the Oracle Integration Cloud instance or the Oracle Public Sector instance can become momentarily unresponsive. While a rare occurrence, you need to be able to resolve any transactions that occurred during the down time to make sure the OIC instance and your Public Sector offering are synchronized.
For example, if OIC is unresponsive for a five minute period according to your system logs and notification system, you can use the Inconsistent Instances page to isolate any transactions that occurred specifically during that time to make sure individual transaction statuses are in sync with the associated workflow process.
Using the Inconsistent Instances Page
Use the Inconsistent Details page to search for transactions created during a specific time range.
Access the Inconsistent Instances page by selecting
. Page Element |
Description |
---|---|
Which system is restored |
Select the system that was not available for a period of time and needed to be restored from a back up. Options are:
If one of the systems is unavailable for a given period and needed to be restored, then the other system becomes the most current source of transaction status for any manual synchronization. |
From/To |
Use the date/time controls to specify a time range for isolating the affected transactions. |
Workflow Instance ID |
The workflow instance ID assigned for a specific transaction by the OIC system when that transaction is submitted. |
Process Status |
The current status of the process, such as CANCELLED, OPEN, COMPLETED, and so on. |
Transaction |
The unique ID of a specific submitted transaction, which is comprised of the topic type and the auto number rule. |
Transaction Status |
The current status of the individual transaction according to the corresponding workflow process definition, such as Submitted, Inspection, Plan Review, and so on. |
Process Definition |
The workflow process definition in OIC to which the specific transaction is associated. This value is comprised of the OIC instance name, the space name, and the workflow process application name as defined in OIC. |
Transaction Update Date |
The last time the transaction was updated. |
Process Update Date |
The last time the process was updated.
|
Using the Details Page
Use the Details page to drill into a specific transaction and take action to resolve any discrepancies between the OIC and PSCR systems. The Details page contains the transaction history in sequential order between the two systems for a given transaction.
Access the Details page by clicking on any row in the grid on the Inconsistent Instances page.
This example illustrates sample data as it would appear in the Details page.
![Inconsistent Instances Details page](images/i49fb084dn-4a33.png)
At the top of the Details page the Oracle Integration Cloud and the Oracle Public Sector Compliance and Regulation sections display a high-level view of the current status for that transaction in the respective systems.
Depending on the information displayed, you may elect to perform different actions, which appear as buttons on the right hand side of the Details page.
Page Element |
|
---|---|
Done |
Closes the Details page with no action taken. Equivalent to Cancel. |
Cancel Workflow |
Cancels the transaction association with the underlying workflow so the transaction can be resubmitted. All previous work would be lost. |
Alter Workflow |
Enables the system administrator to alter the workflow manually to ensure both systems are in sync in the event of an momentary unavailability of either system. For more information on the options when altering workflow, see Using Workflow. |
Resubmit Application |
Enables the system administrator to resubmit an application. |
Page Element |
Description |
---|---|
Process ID |
The workflow instance ID assigned for a specific transaction by the OIC system when that transaction is submitted. |
Transaction ID |
The unique ID of a specific submitted transaction, which is based on the auto number rule. |
Applicant ID |
The unique ID of the applicant who submitted the transaction intake form. |
Transaction Type |
The transaction type as defined on the Transaction Type page. For example, for a permit this will be the Permit Type value. |
Last Task |
The last task in the workflow process definition that the transaction has reached. (Applies only to the OIC system.) |
Last Action Taken |
The action taken on the last task. (Applies only to the OIC system.) |
Transaction Status |
The current status of the transaction reflected in the PSCR system, such as In Process, Accepted, and so on. |
Page Element |
Description |
---|---|
Service Type |
Indicates what service handled the request. Options are:
|
Task Information |
The task information associated with the task defined in the workflow process definition. |
Assigned By |
The user name of the individual to who assigned the current task to the assignee. |
Assigned To |
The user name of the individual to whom the current task is assigned. |
Updated By |
The user name of the individual who updated the task. |
Task Creation Date |
The date and time the task in the workflow process definition was initiated for the current transaction. |
Last Action Taken |
The last action taken as reflected in the OIC system. |
Transaction Status |
The status of the transaction reflected in the PSCR system. |
Last Updated Date |
The date and time when the transaction was last updated. |