Introduction to business processes
Business process management systems (BPMS) products such as jBPM have the ability to model and execute multiple business processes. A business process is typically composed of nodes such as events, gateways, and tasks that are connected to each other for defining the process flow. Every type of node has a specific semantic and is instantiated by the process runtime engine when a process instance is executed. Business processes that require human interaction are modelled by using human task nodes. The following image shows a process where three tasks require human interaction:

BPM standard task assigning
In general, business process runtime engines assign human tasks to users on a group basis. The target audience is usually included as part of the human task configuration. The following image shows how the Review Purchase Order human task is configured with the PurchaseDepartment group:

wbadmin user. After the user claims the task, he is known as the task “actual owner”.

OptaPlanner driven task assigning
OptaPlanner and jBPM integration provides the ability to assign the human tasks produced by the process runtime engine between users according to an optimized plan. Instead of users having to claim the tasks, the tasks are assigned to them. The following image shows how the tasks are assigned when integration is enabled.
- User katy is assigned to tasks #150 and #148
- User john is assigned to tasks #151 and #149
- Tasks #152, #153, #154, #155, #156 and #157 are left un-assigned (these tasks will be analysed later)
- All of the available tasks with the status “Ready” were consumed by OptaPlanner.
- The users john and katy were identified as belonging to the “PurchaseDepartment” users group.
- The “Review Purchase Order” tasks were identified as defined for the “PurchaseDepartment” group.
- An optimized plan was calculated and all of the tasks (including the “un-assigned” tasks) were assigned according to their configuration, for example group condition and OptaPlanner optimization rules. The resulting plan stated that:
- Tasks #150 and #148 must be assigned to katy
- Tasks #151 and #149 must be assigned to john
- OptaPlanner executed the correct process runtime actions to make these assignments happen. Note that the users were not required to execute the “claim” operation. Instead they can focus on completing their respective assigned work and leave the distribution and assignment work to OptaPlanner.
- User katy is assigned to tasks #150 and #148 which belong to the planning window
- User john is assigned to tasks #151 and #149 which belong to the planning window
- The un-assigned tasks are outside of the planning window which means they are assigned only internally by OptaPlanner. As long as these tasks remain unpublished they can be reassigned if necessary during the different optimized plans calculation.
Configuring the integration
Product version
The current task assigning integration implementation is provided for the OptaPlanner, jBPM, and KIE Server 7.38.x+ series.- Install the KIE Servers topology that you require.
-
If you are using the jBPM schema generation scripts be sure to execute the following sql script corresponding to the target database management system:
jBPM installer →
/db/ddl-scripts/<dbms_vendor>/task_assigning_tables_<dbms_vendor>.sqlFor example, in the case of a db2 database you must execute the following script: jBPM installer →/db/ddl-scripts/db2/task_assigning_tables_db2.sqlFor more information related to these scripts see jBPM documentation. Note: the reverse script in cases where the generated schema needs to be deleted can be found in the same location and has the following name:task_assigning_tables_drop_<dbms_vendor>.sql - Be sure the process runtime is executing well.
- Install a dedicated Planning kie-server (see next topics).
- Complete the task assigning integration specific configuration parameters in all of the associated Process Runtime kie-servers and the Planning kie-server.
Simplified architecture
The following simplified architecture identifies the key components and configuration parameters for the task assigning integration.
Process Runtime kie-server
This is the KIE Server instance where the business processes execute. In clustered and high-availability configurations, multiple instances can be used.Planning kie-server
This is the KIE Server instance where OptaPlanner will execute, for example where the optimized plans and so forth will be calculated, and where the UserSystemService integration component will run. The task assigning integration requires a single dedicated KIE Server instance for this purpose. Be sure no other KIE Server extensions are enabled on this server.Configuration parameters setup
All of the configuration parameters that are defined in the next topics are defined through the Java system properties. In Wildfly and Red Hat Enterprise Application Server (EAP) installations, these parameters are usually configured in the<system-properties> section of the selected configuration file, for example:
Process Runtime kie-server configuration
The following table shows the only parameter that must be configured in all of the Process Runtime kie-servers in the target topology.| Parameter | Requirement | Description |
|---|---|---|
| org.kie.server.taskAssigning.runtime.ext.disabled | Not required | The default value is “true”, meaning that the task assigning integration is always disabled. Must be set to “false” for making it work. |
Process Runtime kie-server Wildfly/EAP configuration example
Planning kie-server configuration
The following topics explain the parameters that you must configure in the Planning kie-server. Whatever the target topology is, only one instance of this server will exist.Global configuration parameters
| Parameter | Requirement | Description |
|---|---|---|
| org.kie.server.taskAssigning.planning.ext.disabled | Not required | The default value is “true”, meaning that the task assigning integration is always disabled. Must be set to “false” for making it work. |
| org.kie.server.services.taskAssigning.core.model.planningUserId | Required | The default value is “planninguser”. This value configures the user for being assigned with the tasks that no other user in the system can be assigned to. For example, if a task has a required skill “astronaut” and no user can be found with this skill, it will be assigned to the planninguser. But it is not only restricted to skills, another example might be a task configured for a users group “Finance”. If no user exists in that group it will be assigned to the planning user. It is strongly recommended that the planning user has the required human tasks administration grants in all of the target Process Runtime kie-servers. By doing so it can easily proceed to track and eventually re-assign the tasks that couldn’t be managed by the tasks assigning integration. Note: it is recommended to keep this name. |
| org.kie.server.taskAssigning.processRuntime.url | Required | The default value is http://localhost:8080/kie-server/services/rest/server This value configures the URL for connecting to the Process Runtime kie-server rest services. In a clustered environment a list of ”|” separated urls can be used for doing load balancing between the different Process Runtime kie-servers. |
| org.kie.server.taskAssigning.processRuntime.user | Required | The default value is wbadmin This value configures the user id for connecting to the Process Runtime kie-server. In a clustered environment it must exist in all of the configured target servers. The configured user must belong to the human tasks administration group. This group is usually found by looking at the target Process Runtime kie-server configuration parameter:
Following the example above the configured user must belong to the group “process-admin” |
| org.kie.server.taskAssigning.processRuntime.pwd | Required | No default value is set. This value configures the password for the user configured in org.kie.server.taskAssigning.processRuntime.user parameter. |
| org.kie.server.taskAssigning.processRuntime.targetUser | Required | No default value is set. This value configures the user ID used to execute the process runtime operations “on behalf of”, and is usually the same as the value of the org.kie.server.taskAssigning.processRuntime.user parameter |
| org.kie.server.taskAssigning.processRuntime.key.alias | Not Required | No default value is set. This parameter can be used in cases where it is required to get the runtime user password from the KIE Server keystore and represents the alias for locating it. |
| org.kie.server.taskAssigning.processRuntime.key.pwd | Not Required | No default value is set. This parameter must be used in cases where the runtime user password is stored in the KIE Server keystore, and represents the password for accessing the corresponding keystore entry. |
| kie.keystore.keyStoreURL | Not Required | No default value is set. URL for the JCEKS that you want to use, for example file:///home/kie/keystores/keystore.jceks |
| kie.keystore.keyStorePwd | Not Required | No default value is set. Password for the JCEKS |
| org.kie.server.taskAssigning.processRuntime.timeout | Not Required | The default value is 90000. This value configures the timeout in milliseconds for the operation invocations on the Process runtime kie-server. |
| org.kie.server.taskAssigning.runtimeDelegate.pageSize | Not Required | The default value is 3000. This value configures the page size for the paged queries. The default value is good for most scenarios and it’s not recommended to be modified unless specific fine tunings are required. |
| org.kie.server.taskAssigning.solutionSyncInterval | Required | The default value is “PT2S” (two seconds). This value configures the time interval for the tasks information refreshing from the Process Runtime kie-server. The accepted format is based on the ISO-8601 duration format PnDTnHnMn.nS with days considered to be exactly 24 hours. For example: “PT1.500S”: configures 1500 milliseconds. ”PT0.500S”: configures 500 milliseconds. ”PT3S”: configures 3000 milliseconds. |
| org.kie.server.taskAssigning.solutionSyncQueriesShift | Required | The default value is “PT10M” This value configures a timeshift for adjusting the tasks information refreshing queries. In most cases it should never be modified and should not be less than PT5M (five minutes). The accepted format is based on the ISO-8601 duration format PnDTnHnMn.nS with days considered to be exactly 24 hours. |
| org.kie.server.taskAssigning.publishWindowSize | Required | The default value is 2. This value configures the maximum amount of tasks per user that will be assigned to it in the Process Runtime kie-server when an optimized plan is calculated. See “published tasks” This value should usually be low, 2, 3, or 4, since it is expected that the tasks will be assigned to the users according to an optimized plan that is changing over time. High values might lead to the BPM Standard task assigning which could make the tasks assigning integration senseless. |
| org.kie.server.taskAssigning.usersSyncInterval | Required | The default value is “PT2H” (two hours) This value configures the time interval for the user’s information refreshing from the UserSystemService integration component. The accepted format is based on the ISO-8601 duration format PnDTnHnMn.nS with days considered to be exactly 24 hours. |
| org.kie.server.taskAssigning.waitForImprovedSolutionDuration | Not Required | The default value is “PT0S” (no wait) This value configures the time interval to improve a solution before the corresponding optimized plan is sent to the Process Runtime kie-server. Because this wait time is applied every time a new set of changes is processed it should usually be short, for example “PT0.500” (500 milliseconds). Use it in cases when early improvements are desired. The accepted format is based on the ISO-8601 duration format PnDTnHnMn.nS with days considered to be exactly 24 hours. |
| org.kie.server.taskAssigning.improveSolutionOnBackgroundDuration | Not Required | The default value is “PT1M” (one minute) This value configures the time interval for doing a background optimization of the current solution after the corresponding optimized plan is sent to the Process Runtime kie-server. In situations where no changes in the processes are produced and a better solution is calculated during that period, the new optimized plan is automatically sent to the Process Runtime kie-server. The accepted format is based on the ISO-8601 duration format PnDTnHnMn.nS with days considered to be exactly 24 hours. |
Solver configuration parameters
As mentioned, the task assigning integration delegates the calculation of “which tasks must be assigned to whom” to OptaPlanner, which resolves this requirement by producing an optimized plan. This plan is calculated by using a Solver with a set of configured constraints. See OptaPlanner product documentation for more information. Two mechanisms are available for configuring OptaPlanner’s Solver specifics. Note: The parameter tagged as “Required” must have a value independently of the selected Solver configuration mechanism.Class path based solver configuration
This mechanism implements the ability of configuring the Solver by using a class path resource.| Parameter | Requirement | Description |
|---|---|---|
| org.kie.server.taskAssigning.solver.configResource | Required | The default value is: “org/kie/server/services/taskassigning/solver/taskAssigningDefaultSolverConfig.xml” This value configures the path to a class-path resource with the Solver configuration. If the resource can’t be found or the configuration is wrong, a controlled error will be added to the Planning kie-server error messages and the task assigning integration won’t be initialized. The KIE Server APIs can be used for querying these error messages and checking the status. |
| org.kie.server.taskAssigning.solver.moveThreadCount | Not Required | The default value is AUTO. This value configures the solver’s ability of using multithreaded incremental solving. For more information see OptaPlanner documentation. Note: when the container based solver configuration is used this value is not considered, the configuration provided in the KJAR is used instead. |
| org.kie.server.taskAssigning.solver.moveThreadBufferSize | Not Required | No default value is set. This value power tweaks the number of moves that are selected but won’t be foraged when multithreaded incremental solving is used. Setting it too low reduces performance, but setting it too high too. Unless you’re deeply familiar with the inner workings of multithreaded solving, don’t configure this parameter. For more information see OptaPlanner documentation. Note: when the container based solver configuration is used this value is not considered, the configuration provided in the KJAR is used instead. |
| org.kie.server.taskAssigning.solver.threadFactoryClass | Not Required | No default value is set. The threadFactoryClass allows you to plug in a custom ThreadFactory for environments where arbitrary thread creation should be avoided. For more information see OptaPlanner documentation. Note: when the container based solver configuration is used this value is not considered, the configuration provided in the KJAR is used instead. |
Container based solver configuration
This mechanism implements the ability to configure the Solver by using a container. Finally, given that the KIE Server architecture is based on containers, this is usually the recommended approach. However, in many of the use cases the default configuration is good enough and no container configuration is necessary, see Default Constraints. The following table shows the container-based configuration parameters:| Parameter | Requirement | Description |
|---|---|---|
| org.kie.server.taskAssigning.solver.container.id | Not Required | No default value is set. This value configures the Identifier of the container to use. When set the container based configuration will be activated and the following container related parameters are required. |
| org.kie.server.taskAssigning.solver.container.groupId | Required if the container configuration is activated | No default value is set. This value configures the Maven groupId of the artifact to use for creating the container when needed. |
| org.kie.server.taskAssigning.solver.container.artifactId | Required if the container configuration is activated | No default value is set. This value configures the Maven artifactId for the artifact to use for creating the container when needed. |
| org.kie.server.taskAssigning.solver.container.version | Required if the container configuration is activated | No default value is set. This value configures the Maven version for the artifact to use for creating the container when needed. |
| org.kie.server.taskAssigning.solver.configResource | Required if the container configuration is activated | This value configures the path to the resource with the Solver configuration in the container class-path. |
UserSystemService integration component
Calculating an optimized plan for assigning tasks to users often requires considering business related information. Common examples, included in the current task assigning integration version, are the usage of the groups, the skills that a given user has, or the affinities in certain topics, etc. See Skills and Affinities. This business oriented information must be provided by each particular installation and is delegated to the UserSystemService integration component. It is up to the tasks assigning integrator to provide this component. UserSystemService API A user system service component must implement the following API.UserSystemService configuration
Analogous to the Solver configuration, two mechanisms are available for configuring the UserSystemService and in both cases the standard Java SPI (Service Provider Interface) and ServiceLoader mechanisms are used for its instantiation.Class path based UserSystemService configuration
Use the following resource for configuring the different UserSystemService provider implementations: META-INF/services/org.kie.server.services.taskassigning.user.system.api.UserSystemService And finally add the following configuration parameters for configuring the selected implementation:| Parameter | Requirement | Description |
|---|---|---|
| org.kie.server.taskAssigning.userSystem.name | Required | No default value is set. This value configures the name of the UserSystemService provider instance to use. See: UserSystemService.getName() All of the configured providers are loaded from the application class-path and the one that matches with the configured name will be used. A simple user system service implementation is provided, see SimpleUserSystemService. |
Container based UserSystemService configuration
Use the following resource in your Kie Module (KJAR) to configure the different UserSystemService provider implementations: project_home/src/main/resources/META-INF/services/org.kie.server.services.taskassigning.user.system.api.UserSystemService And finally add the following configuration parameters for configuring the selected implementation:| Parameter | Requirement | Description |
|---|---|---|
| org.kie.server.taskAssigning.userSystem.name | Required | No default value is set. This value configures the name of the UserSystemService provider instance to use. See: UserSystemService.getName() |
| org.kie.server.taskAssigning.userSystem.container.id | Not Required | No default value is set. This value configures the Identifier of the container to use. When set the container based configuration will be activated and all of the potential UserSystemService providers that might be defined in the container class-path will be considered for selection, additionally to the ones in the application class-path. The following parameters will be required. |
| org.kie.server.taskAssigning.userSystem.container.groupId | Required if the container configuration is activated. | No default value is set. This value configures the Maven groupId of the artifact to use for creating the container when needed. |
| org.kie.server.taskAssigning.userSystem.container.artifactId | Required if the container configuration is activated. | No default value is set. This value configures the Maven artifactId for the artifact to use for creating the container when needed. |
| org.kie.server.taskAssigning.userSystem.container.version | Required if the container configuration is activated. | No default value is set. This value configures the Maven version for the artifact to use for creating the container when needed. |
SimpleUserSystemService
The SimpleUserSystemService is a basic UserSystemService implementation that loads the user definitions, skills and affinities from a Java properties file in the format used by the Wildfly/EAP application servers. This implementation is always present in the Planning kie-server and is intended mainly for development and testing purposes. The following example shows a user definitions file:- User katy that belongs to the groups analyst and HR
- User john that belongs to the groups IT and Developer
| Parameter | Requirement | Description |
|---|---|---|
| org.kie.server.taskAssigning.userSystem.name | Required | Must be the value SimpleUserSystemService |
| org.kie.server.services.taskassigning.user.system.simple.users | Required | This value configures a Planning kie-server web application accessible path with the user definitions file. For example, in Wildfly/EAP installations it can be like this.
Note: the configured file must have the same values as the roles.properties files of the Process Runtime kie-servers in the target topology. |
| org.kie.server.services.taskassigning.user.system.simple.skills | Not Required | This value configures a Planning kie-server web application accessible path with the users skills definitions if desired, see Skills and Affinities. For example, in Wildfly/EAP installations it can be like this.
Note: the format is analogous to the user definitions file. katy=skill1,skill2 |
| org.kie.server.services.taskassigning.user.system.simple.affinities | Not Required | This value configures a Planning kie-server web application accessible path with the users affinities definition if desired, Skills and Affinities. For example, in Wildfly/EAP installations it can be like this.
Note: the format is analogous to the user definitions file. katy=affinity1,affinity4 |
Planning kie-server Wildfly/EAP configuration example
Below is an extract of the task assigning configuration parameters for a Wildfly/EAP server.Spring Boot configuration
When the KIE Server Spring Boot Starter version is used the following configuration parameters are used to configure the task assigning integration. These parameters are usually configured in the corresponding Spring Boot application.properties file. The same statements as for standard KIE Server topologies apply in this case.Default Constraints
The following table gives a high level description of the set of constraints that are included in the task assigning integration. These constraints are used for the construction of the optimized plan, in other words “for determining which tasks should be assigned to whom”. In general a large set of use cases can be covered by using them and no extensions are required, but it is possible to work with a user-provided customized set of constraints if needed, see Container based solver configuration. Optimized solutions construction is made by using a BendableLongScore with two levels of Hard constraints and six levels of Soft constraints. These constraint levels can be customized by following a set of restrictions.| Constraint | Level/Requirement | Description |
|---|---|---|
| Required Potential Owner | Hard Constraint 0 (required) | Determines that a task must be assigned to one of its “Potential Owners”, or to the “Planning User” in cases where no “Potential Owners” are found. User provided customizations must always include this constraint as the first level hard constraint. Otherwise the business process semantics won’t be considered by the task assigning integration, i.e., tasks might be assigned to users that are not “Potential Owners” for it. In cases where this constraint is still customized, it must always consider assigning the “Planning User” when no other user fits the customized condition. |
| Required Skills | Hard Constraint 1 | Determines that a task can only be assigned to a user that has all of the task’s configured skills, see Skills and Affinities. If a task has configured skills but no user with all of these skills can be found it’ll be assigned to the “Planning User”. If the task doesn’t have configured skills the constraint has no effect. In cases where this constraint is customized, it must always consider assigning the “Planning User” when no other user fits the customized condition. |
| PlanningUser assignment | Soft Constraint 0 (required) | Penalizes the “Planning User” assignment. This constraint enforces the minimization of the “Planning User” assignment and ensures it’ll be assigned as the “last available option”. Do not customize or change this constraint. |
| High level priority | Soft Constraint 1 | Enforces the assignment of higher priority tasks first whenever it is possible. |
| Desired Affinities | Soft Constraint 2 | Makes a best effort for assigning tasks according to its configured affinities, see Skills and Affinities If a task has configured affinities, whenever it is possible, a user with the most of them will be picked for its assignment. If the task doesn’t have configured affinities the constraint has no effect. |
| Minimize makespan | Soft Constraint 3 (required) | Reduce the time to complete all tasks. This constraint must always be included. |
| Medium level priority | Soft Constraint 4 | Medium level priority tasks are assigned after higher priority tasks whenever it is possible. |
| Low level priority | Soft Constraint 5 | Low level priority tasks are assigned last whenever it is possible. |
Constraints configuration by using a DRL file
The following example shows the key parts of the DRL file that contains the constraints configurations.Skills and Affinities
The use of skills and affinities implements the ability of declaring business related data for being considered by the default provided constraints or any other user defined ones. This is a fine grained decision mechanism that you can use on top of the groups-based assignment semantics defined in the business process. Internally, this mechanism is based on the ability to label the human tasks generated by the business processes runtime and the users information. Labeling mechanism The following procedure shows how the labeling mechanism converts information in human tasks and users information to labels:
- Any human task is created in the processes runtime.
- When the new task is detected by the task assigning solution refreshing mechanism, a set of LabelValueExtractors is applied.
- These LabelValueExtractors can transform any piece of information in the human task or user into a label.
- The default constraints consider these labels.
- The input data “skills”, with the value “skill1, skill2” resulted in the label SKILLS with the following set of values {“skill1”, “skill2”}
- The input data “affinities” with the value “affinity1” resulted in the label AFFINITIES with the following set of values {“affinity1”}

Default HumanTask and User LabelValueExtractors
Four label value extractors are provided to manage the SKILLS and AFFINITIES labels.| Extractor Name | Description |
|---|---|
| DefaultTaskDataSkillsValueExtractor | Processes the human task “skills” input value as a string of comma separated values, and creates a java For example, the “skills” input value “english,finance” is extracted as a set with the values {“english”, “finance”} and assigned to the label with name SKILLS. By default extraction can be customized by using the following system property for defining the task input value from where the SKILLS will be extracted. For example: org.kie.server.services.taskassigning.planning.data.DefaultTaskDataSkillsValueExtractor.skills=someOtherName |
| DefaultTaskDataAffinitiesValueExtractor | Processes the human task “affinities” input value, as a string of comma separated values, and creates a java For example, the “affinities” input value “news,history” is extracted as a set with the values {“news”, “history”} and assigned to the label with name AFFINITIES. By default extraction can be customized by using the following system property for defining the task input value from where the AFFINITIES will be extracted. For example: org.kie.server.services.taskassigning.planning.data.DefaultTaskDataAffinitiesValueExtractor.affinities=someOtherName |
| DefaultUserSkillsValueExtractor | Analogous to the DefaultTaskDataSkillsValueExtractor. By default extraction can be customized by using the following system property for defining the user attribute from where the SKILLS will be extracted. For example: org.kie.server.services.taskassigning.planning.data.DefaultUserSkillsValueExtractor.skills=someOtherName |
| DefaultUserAffinitiesValueExtractor | Analogous to the DefaultTaskDataAffinitiesValueExtractor. By default extraction can be customized by using the following system property for defining the user attribute from where the AFFINITIES will be extracted. For example: org.kie.server.services.taskassigning.planning.data.DefaultUserAffinitiesValueExtractor.affinities=someOtherName |
Linking the human tasks inputs with the labels
A simple approach for labeling tasks with business related information is implemented using the task inputs configuration. The following image shows an example of such a configuration.
Custom extractors
Installations that require the definition of customized LabelValueExtractors can add them by providing their implementations in the customized KJARs with the UserSystemIntegration implementation or the Solver configuration.- Add a component in the specified KJAR that implements the following interface: org.kie.server.api.model.taskassigning.data.LabelValueExtractor Note: Ensure that the following dependency is added to the given KJAR:
- Declare the component implementation by using the Java standard service provider mechanism in the following resource: project_home/src/main/resources/META-INF/services/org.kie.server.api.model.taskassigning.data.LabelValueExtractor
Integration alternatives
System integrators usually consume the human tasks available in the Process Runtime kie-server for different purposes. One example is the Business Central “Task Inbox”. In this case, Business Central acts as an “integrator” which means that the human tasks are consumed from the Process Runtime kie-server by using the kie-server queries APIs and applying different filtering criterias. Finally these tasks are listed in the “Task Inbox” UI, etc. In this way, Business Central is decoupled from the Process Runtime kie-server, etc. The next topics present a set of queries similar to queries used by the Business Central “Task Inbox”. These queries might facilitate integrations in cases where the task assigning integration is enabled.Task Assigning Human Tasks Query
This query facilitates the consumption of the available human tasks. The task can integrate additional information depending on the query variant. It is up to the “integrator” to select the query variant that best supports its needs.Filtering parameters
The available filtering parameters are defined in the following kie-server-api enums:Querying the human tasks as TaskData instances
This query execution variant enables getting the result values as instances of:Examples
Credit dispute process
The following credit dispute process example is intended to show a simple use case where you can use the “skills” configuration to influence the way tasks are assigned according to the solver constraints and the process data.
Process start
When the process starts, the user is asked to complete the information in the following image. In particular, the credit card brand for which the dispute is related to and the preferred language for receiving the process notifications are requested. This information is used for assigning the process tasks.
Process configuration
The following image shows the process variables that are used for holding the card brand and language respectively.
Resolve dispute task configuration
The following image shows the ResolveDispute task configuration, which establishes that the task input parameter skills is assigned with the value of the process variable cardType.
- Are in the user group CreditAnalyst
- Have all of the skills configured in the task input parameter skills
Notify customer task configuration
The following image shows the NotifyCustomer task configuration, which establishes that the task input parameter skills is assigned with the value of the process variable language.
- Are in the group ClientRelations
- Have all of the skills configured in the task input parameter skills
- Note that in this case the language selection is optional since the form field is not marked with ”*” see the process start form, meaning that when no language is selected the task won’t have any configured skills. This implies that in such cases whatever users that are in group ClientRelations can be assigned to the task.
Process execution (example users)
Let’s assume that the following user configurations are used for executing the process. users.properties file:Process execution (example instances)
With the preceding configurations the following execution scenarios are expected: Process instance #1:- Start process

- ResolveDispute task

- NotifyCustomer task

- Start process

- ResolveDispute task

- NotifyCustomer task

- Start process

- ResolveDispute task

- NotifyCustomer task

Customized User System Service
For creating a custom user system service implementation follow these steps:- Create a KJAR project structure
- Add the following dependency
- Provide your UserSystemService implementation, see the following example:
- Add the following resource to the project and declare your user system service provider class on it.
- Build your KJAR and be sure the corresponding maven generated artifact is installed in the maven repository used by your Planning kie-server.
- Add a datasource configuration to your Planning kie-server pointing to the target DB (this step is only required for the example above). For example with JNDI name java:jboss/datasources/db-user-system-datasource
- Finally add the following items to the Planning kie-server configuration file: