Administering human workflow service engines

The human workflow service engine runs as a separate engine in the Oracle SOA Suite 12c service infrastructure providing human task execution functionalities to both BPEL and BPMN processes. The human workflow component consists of a number of services that handle various aspects of human interaction with a business process such as task approvals, rejections, reassignments, delegation, and so on.

An instance of the human workflow service engine can be initiated by an invocation from another service component such as the BPEL or BPMN engines. The message is routed to the engine by the SOA service infrastructure and is persisted by the workflow engine in dehydration store schema. Once an invocation transaction is committed, the instance becomes available for human interactions through a thin client such as a browser or mobile-based user interface. Each update on the instance or the runtime state through a user action is then handled by the engine in a separate transaction.

Describing human workflow components and applications

The human workflow engine allows defining to-do tasks that can be assigned to users or groups of users, giving business users more flexibility and a centralized approach for task management. Workflow tasks can be assigned to application roles and then, at runtime, real users or groups from your enterprise repository defined within your organization can be mapped to these application roles. In this section, you will learn ways to integrate your company's directory server with the service infrastructure and pull organizational users to associate them with application or logical business process roles.

An important feature of the Human Workflow Service Engine is a worklist application built on top of ADF-rich client components. The worklist application is accessible via a web browser, giving business users a common look and feel and developers a standardized approach for building user interfacing applications that are flexible and customizable. Business process users can define their own work queues and share these views with other users and groups. All human workflow data definitions and custom task views can be shared across members within an organization. Logging in to the worklist application is role based and the interface is accessible via the following URL:

http://<soahost>:<soaport>/integration/worklistapp

The human workflow engine leverages the UMS framework deployed in the infrastructure for its notification needs. The UMS engine allows process participants to customize their messaging channels and even set preferred mechanisms of being notified. These preferences, such as the mode to receive notifications (for example, e-mail and SMS), and which devices need to be used, can all be configured from the following address:

http://<soahost>:<soaport>/sdpmessaging/userprefs-ui

Administration of human task instances, workflow service engine configuration, notification setup, and fault management are performed from the Oracle Enterprise Manager Fusion Middleware Control console. It also provides a mechanism to detect and handle auto-reply messages, poisoned responses, and spam in the workflow engine.

Managing workflow task configuration at runtime

Part of Oracle SOA Suite 12c's design is to allow for as much flexibility and agility as possible by enabling runtime changes to various components, such as business rules, domain value maps, and certain aspects of human workflow task configurations. However, business users may still not be prepared to modify these configurations at runtime. For on-demand, human-task-related configuration changes, the onus is then on administrators to edit task assignment and routing policies, modify approval group settings, change business rules responsible for dynamic task allocation, and so on, to enable a change. Human task runtime configuration changes post deployment of composites can be done by following the steps provided here:

  1. Log in to the SOA Composer at http://<soahost>:<soaport>/soa/composer.
  2. Any configuration changes made to resources such as DVMs, tasks, composite sensors, and rules have to be performed within a session. Click on Create Session to initiate a change window.
  3. By default, the SOA Composer organizes resources by Deployment View (that is, by deployed composites that they are packaged into).
  4. Change this to Types View by clicking on the Managing workflow task configuration at runtime icon.
  5. Expand Human Tasks and then click on the task definition you want to edit.
  6. Figure 7.33 shows the task configuration page. This page allows for runtime changes to task routing policies, expiration and escalation policies, and notification settings for a human task after it is deployed to the infrastructure.
  7. After finishing the changes, click on the Publish button for the changes to take effect.
  8. The console will prompt for a session comment to be provided to maintain a change history record.

The following screenshot demonstrates the task configuration page:

Managing workflow task configuration at runtime

Figure 7.33: Configuring Human Task policies from SOA Composer

Managing human task service component address

A human task component in a composite has an associated user-defined task details interface executing on the worklist application. Configuration of the human task service component task detail application URI, say by editing, adding, or removing it can be performed from the Oracle Enterprise Manager Fusion Middleware Control console. This configuration page is different for each human workflow component. Access this by navigating to a specific composite and selecting the human task service component under the Components table. Click on the Administration tab and then on the Add URI button to create an accessible endpoint for the task by providing the Host Name, HTTP Port, or HTTPS Port values for the URI.

The primary reasons why this information (depicted in Figure 7.34) needs to be configured at the task level are as follows:

  • When the SOA managed server in the infrastructure is SSL enabled, you must manually enable SSL by changing the workflow task to use the correct protocol and port number. To enable the use of the SSL (HTTPS) URL, ensure that the HTTP Port setting is left blank.
  • If there is a clustered setup with multiple managed servers servicing incoming requests, then Host Name and HTTP Port will have to be substituted with the frontend host and port of the cluster or the load balancer address, if there is one configured. If there is more than one independent managed server, click on Add URI to enter details for as many of them as you wish to.

The following screenshot shows the URI being updated:

Managing human task service component address

Figure 7.34: Configuring Human Task Workflow Component URI

Seeding organizational users and groups

When human task flow components are created at design time, they are simply mapped to logical or application roles. Upon deployment to the human workflow service engine, you need to assign real human users to participate and act on workflow tasks. Participants can act on tasks during runtime from the worklist application, such as to approve/reject a sales order, delegate approvals, provide feedback on a help desk request, and so on. To engage real users, it is necessary to integrate a directory service to maintain your organization's users and groups, like an LDAP server with the infrastructure running your composites.

By default, the underlying Oracle WebLogic Server identity service uses an embedded LDAP server as the default authentication provider. Figure 7.35 shows the visual steps to change your default authentication provider in an existing security realm with an existing LDAP based directory server:

Seeding organizational users and groups

Figure 7.35: Registering an LDAP server as Authentication Provider in WebLogic Server

The sequence of steps to create a new LDAP authentication provider is as follows:

  1. Log in to the Oracle WebLogic Server Administration Console.
  2. Click on Security Realms under the Your Application's Security Settings pane.
  3. Click on the name of a realm in the list (myrealm is the default realm).
  4. Navigate to Providers | Authentication and click on the New button.
  5. When the Create a New Authentication Provider page appears, type a name for the provider (for example, LDAP), and select LDAPAuthenticator on the Type dropdown.
  6. Clicking on OK will create the authentication provider skeleton without the actual configuration. Additional configuration properties are required to point it to an actual active directory server.
  7. Click on the authentication provider that was just created.
  8. From the Control Flag drop-down list, choose SUFFICIENT (do the same for all other authenticators too), and click on Save. This flag instructs the WebLogic Server to accept authentication from this authenticator and not invoke additional authenticators. If the authentication fails, the server will attempt to authenticate a user using the next authenticator in the hierarchy list.
  9. Next, go to the Provider Specific tab to specify connection parameters of the authenticator server. The following table provides a brief explanation of some of the properties.
  10. Enter the provider-specific information about the authentication provider, check the Use Retrieved User Name as Principal checkbox, and click on Save.

Here are the properties to connect to an LDAP server:

Provider-specific property

Remarks

Host

The hostname or IP address of the authenticator (for example, ausdcx64ldap.packt.com).

Port

The port number on which the authenticator server is running. The default is 389.

Principal

The Distinguished Name (DN) of the authentication server user that WebLogic Server should use when connecting to it. An example principal is as follows:

CN=ServiceLDAP,OU=Service Accounts,DC=packt,DC=com

Credential

The credential property is usually a password used to connect to the authenticator server.

User Base DN

The base Distinguished Name (DN) of the tree in the LDAP directory that contains users (for example, DC=packt, DC=com).

Group Base DN

The base Distinguished Name (DN) of the tree in the LDAP directory that contains groups.

Use Retrieved User Name as Principal

Specifies whether to use the user name retrieved from the LDAP server as the principal in the subject.

User Name Attribute

The attribute of an LDAP user object class that specifies the name of the user (for example, UID, CN, MAIL, and so on) (for example, sAMAccountName).

These properties are sufficient to connect to an LDAP server. Use the default setting for the rest of the fields if in case these values are not known.

  1. Click on Security Realms | Providers | Authentication to return to the list of authentication providers and click Reorder to move the new provider to top.
  2. After reordering, Default Authenticator should appear at the bottom of the list. This action enables the system to handle logins such as weblogic that are not typically in an LDAP directory but must still be authenticated to start the server.
  3. Once these changes are saved and the changes are activated, a restart of both the admin and all managed servers is required.

After the restart, under the Users and Groups tab in Security Realms, all of the organization's users and groups set up in Active Directory are listed alphabetically, as shown in the following screenshot:

Seeding organizational users and groups

Figure 7.36: Registering an LDAP server as the Authentication Provider in WebLogic Server

By default, only usernames in human tasks are case agnostic (case insensitive). This behavior is controlled by the value of the caseSensitive property in System MBeans Browser for users, which is set to false by default. Group names in human tasks must be identical to what is seeded in the user directory. However, if you also want group names in human tasks to be case agnostic, you must set the caseSensitiveGroups property to false. To enable case-agnostic behavior for group names in human tasks, follow these steps:

  1. Log in to Oracle Enterprise Manager Fusion Middleware Control.
  2. Right-click on soa-infra and navigate to Administration | System MBean Browser.
  3. Expand Application Defined MBeans | oracle.as.soainfra.config | [server_name] | WorkflowIdentityConfig | human-workflow | WorkflowIdentityConfig.PropertyType | caseSensitiveGroups.
  4. Click on the Operations tab.
  5. Click on the setValue property.
  6. Enter a value of false in the form field, and click on Invoke.

Mapping users and groups to application roles

Every deployed component or module (both custom and out of the box) in Oracle SOA Suite 12c inherits a security model where users or groups available from an organization have to be mapped to appropriate application roles. For example, you might want to give certain users in the organization the right to access and edit human task configurations from the SOA Composer at runtime, or in case of a deployed BPM project, map users to swimlane roles. Mapping users and groups to application roles is a regular administrative activity for large scale SOA and BPM implementations in an organization. The following steps along with Figure 7.37 outline a mechanism to achieve this:

  1. Log in to Oracle Enterprise Manager Fusion Middleware Control.
  2. Under the navigator, select WebLogic Domain | [Domain_Name] | Weblogic Domain | Security | Application Roles.
  3. To search for a specific role, select the radio button beside Select Application Stripe to Search.
  4. The dropdown is now enabled. Select OracleBPMProcessRolesApp and press the Mapping users and groups to application roles icon. All default application roles for this application stripe are listed.
  5. Alternatively, enter an existing and known role name in the search text box to retrieve matching roles in the stripe.
  6. From the retrieved tabular list of available roles, click on any role (in this example, OrderBookingComposite.SalesAgent) under the Role Name column. This enables an option to add available users or groups to the selected role.
  7. Click on the Add button, where a wildcard-based search can be performed to retrieve a list of matching users from the configured directory providers.
  8. Select a user from the list Searched Principals and click on the OK button to add them to the role.

The same steps can be used to associate groups in organizations or other available Application Roles to the selected role. Take a look at the following screenshot:

Mapping users and groups to application roles

Figure 7.37: Mapping organizational users to Application Roles

Configuring multiple authentication providers for human workflow

When working with human workflow based composites, customers frequently have an external identity store that acts as a directory, holding the application end users and related enterprise groups. In many cases, they may also want to keep WebLogic's embedded LDAP server for administration accounts. Many large organizations also tend to have multiple user directories based on geographies, but the human workflow solution may require all users and groups to be brought together. If multiple authentication providers are configured, authentication occurs through all of them, according to the control flags set. Java Portlet Specification (JPS) however provides authorization in order of the hierarchical list of providers. An additional LDAP authentication provider can be configured for the worklist application but Oracle Platform Security Services (OPSS) by default doesn't support multiple authenticators. To overcome this challenge, Oracle SOA Suite 12c bundles a library named LibOVD, providing virtualization capabilities over multiple LDAP authentication providers.

To configure support for multiple authentication providers, a prerequisite is to have the Control Flag for all the providers set to SUFFICIENT. This can be set by accessing the property from the WebLogic Server Administration Console by navigating to Security Realms | myrealm | Providers | Authentication | [Provider] | Common.

Once this property change is implemented, support for multiple authentication providers can be configured through any one of the following options:

Option 1: A configuration change through Enterprise Manager Fusion Middleware Control:

  1. Log in to Oracle Enterprise Manager Fusion Middleware Control.
  2. Navigate to WebLogic Domain | [Domain Name] | Security | Security Provider Configuration | Identity Store Provider and click on the Configure button.
  3. Add a new property named virtualize and set its value to true, as shown in Figure 7.38.
  4. Click OK to save the changes.
    Configuring multiple authentication providers for human workflow

    Figure 7.38: Adding support for multiple authentication providers for Human Workflow Components

Option 2: Modifying the jps-config.xml file:

  1. Change selection to the $DOMAIN_HOME/config/fmwconfig directory and take a backup of the jps-config.xml file.
  2. Next, edit the file and modify the service instance idstore.ldap.provider to add the virtualization flag.

Let's have a look the following configuration snippet:

<serviceInstance provider='idstore.ldap.provider' name= 'idstore.ldap'>
  <property value= 'oracle.security.jps.wls.internal.idstore. WlsLdapIdStoreConfigProvider' name="idstore.config.provider"/><property value='oracle.security.idm.providers.stdldap.JNDIPool' name='CONNECTION_POOL_CLASS'/><property value='true' name='virtualize'/>
</serviceInstance>

Both these options require a domain level restart.

Migrating human workflow data from test to production

Process participants working on tasks assigned to them in the worklist or the workspace application may not find the default inbox view very helpful. For instance, they may need to view additional columns required to prioritize tasks or view process indicators in the inbox. These additional columns may be added from the default available column list, or users may use a mapped attributes (flex fields) to store and display important values from the task payload. Mapped attributes in human workflow store and query custom attributes that typically come from the task payload values.

However, the problems it poses for you as an administrator, in the long run, is migrating worklist customizations across different environments. Assume that a bunch of participants create custom views and vacation rules and add mapped attributes in the test environment, which are then necessary to promote to staging and production environments. Oracle SOA Suite 12c provides a Human Workflow User Config Data Migrator that is available as a utility script wrapped with Ant.

The Data Migrator provides administrators the following operations:

  • Export: This operation extracts all the human workflow user-configurable data from the source SOA server and saves it to an XML file.
  • Import: This operation recreates all human workflow custom configurations and imports data in the target SOA server by reading them from a source XML file.

The Data Migrator utility relies on two key files:

  • The migration.properties: This contains all required input properties in terms of key-value pairs for migration operations. It also determines what type of user configuration is to be imported or exported.
  • The ant-worklist-t2p.xml: This is an Ant build file containing the default Ant target, runHwfMigrator, responsible for exporting customizations from one environment and importing them to another depending upon the operation.

Figure 7.39 shows a custom view configured by the weblogic user in the worklist application for task approvals. A Priority Approvals view is configured to accommodate and show the orderDiscount field (mapped attribute) on the worklist screen. The following section will describe how to set up and execute the Data Migrator wizard to extract these customizations in an XML file and then import them into another server. Observe the following screenshot:

Migrating human workflow data from test to production

Figure 7.39: Custom views and mapped attributes in the BPM Worklist Application

To move human workflow data from test to production environments, perform the following steps:

  1. Ensure that the PATH environment variable contains JAVA_HOME (the location of the complaint JDK path) and ANT_HOME.
    export JAVA_HOME=/u01/app/oracle/middleware/jdk1.7.0_15
export ANT_HOME=$MW_HOME/oracle_common/modules/org.apache.ant_1.9.2
export PATH=$PATH:$JAVA_HOME/bin:$ANT_HOME/bin
  2. Now, change the prompt to $MW_HOME/soa/bin.
  3. Create a migration.properties file in the bin directory to export user metadata for the worklist application (for example, group rules, views, mapped attribute mappings, and vacation rules) from the test environment. See here one such example of a migration.properties that contains properties to export custom worklist views. The connection and file location properties highlighted in the following snippet need to be replaced with values corresponding to your environment:
    # Connection Properties
soa.hostname = localhost
soa.rmi.port = 8001
soa.admin.user = weblogic
soa.admin.password = welcome1
realm = jazn.com

# Migration File Location
migration.file = /tmp/worklist_data/export_all_migration.xml
map.file = /tmp/export_all_map_mapper.xml

# hwfMigrator Properties
operationType = EXPORT
objectType = VIEW
name = ALL
user = weblogic
group =
grantPermission = true
migrateAttributeLabel = true
override = true
skip = true
migrateToActiveVersion = true
  4. The directory has an Ant build file containing the runHwfMigrator default target. Execute the Ant command by passing ant-t2p-worklist.xml as the file argument to export user configuration data.
    ant -f ant-t2p-worklist.xml -Dbea.home=$MW_HOME -Dsoa.home=$MW_HOME/soa
  5. If all properties are correctly specified, you will get a successful build output and two files will be created in /tmp/worklist_date.
  6. Figure 7.40 shows how to verify that the export was successful by locating the migration and map file in the directory specified in the migration.properties file. The export_all_migration.xml file contains exported data for the Priority Approval View along with its view columns.

The following table explains each of the properties in detail:

Property

Definition

migration.file

This specifies the directory location where task definition mapping data is exported to or imported from.

map.file

This specifies the directory location where user configuration data is exported to or imported from.

operationType

Flag this to specify whether to export data from the server or import into it.

objectType

This property specifies the type of custom object to migrate. Possible values are either VIEW, RULE, and TASK_PAYLOAD_FLEX_FIELD_MAPPING.

Name

This specifies the object name if you specified VIEW or TASK_PAYLOAD_FLEX_FIELD_MAPPING values for the objectType properties. You can specify an individual viewName or taskDefinitionId. Specify ALL to identify all objects of this type.

User

This specifies the username for VIEW or RULE objectType properties. If a user is not specified for a VIEW, it implies STANDARD_VIEW.

Group

This specifies the group for only RULE objectType property to identify the group name. Leave it blank if the username property is specified.

grantPermission

A true flag migrates view definitions and grants whereas a false value migrates only view definitions. Applicable only for the VIEW objectType property.

migrateAttributeLabel

A true value migrates only attribute labels whereas the false flag doesn't migrate attribute labels.

Override

While using the IMPORT operationType this property species whether to override the data on the target SOA server if the flag is set to true.

Skip

If an error happens while migrating a true value of this flag specifies that errors are skipped and the migration utility continues processing. If set to false, the migration is halted if an error occurs.

migrateToActiveVersion

A true value maps task definition IDs to the active version in the target SOA server instance.

Let's have a look at the following screenshot:

Migrating human workflow data from test to production

Figure 7.40: Output mapping and migration files from Worklist T2P Utility

However, keep the following things in mind while using the migration utility:

  • Only one type of data (objectType) can be exported or imported at a time.
  • Each particular user or group's data must be exported or imported in separate operations.
  • Attribute labels must be exported or imported before mapped attribute mappings.
  • Human workflow artifacts, such as task-mapped attribute mappings, rules, views, and approval groups, are defined based on namespace. The worklist data migration utility migrates human workflow artifacts based on namespace. Therefore, it is not possible to migrate human workflow artifacts based on a partition.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.138.119.106