• favor use of RuntimeManager and RuntimeEngine whenever performing work instead of using cached ksession and task service instance
• Cache only RuntimeManager not RuntimeEngine or runtime engine's components
• Creating runtime manger requires configuration of various components via runtime environment - way more simplified compared to version 5 but still...
• On request basis always get new RuntimeEngine with valid context, work with ksession, task service and then dispose runtime engine

• jbpm-services-api - contains only api classes and interfaces
• jbpm-kie-services - rewritten code implementation of services api - pure java, no framework dependencies
• jbpm-services-cdi - CDI wrapper on top of core services implementation
• jbpm-services-ejb-api - extension to services api for ejb needs
• jbpm-services-ejb-impl - EJB wrappers on top of core services implementation
• jbpm-services-ejb-client - EJB remote client implementation - currently only for JBoss

DefinitionService

• process definition - id, name, description
• process variables - name and type
• reusable subprocesses used in the process (if any)
• service tasks (domain specific activities)
• user tasks including assignment information
• task data input and output information

String processId = "org.jbpm.writedocument";

Collection<UserTaskDefinition> processTasks = 
bpmn2Service.getTasksDefinitions(deploymentUnit.getIdentifier(), processId);

Map<String, String> processData = 
bpmn2Service.getProcessVariables(deploymentUnit.getIdentifier(), processId);

Map<String, String> taskInputMappings = 
bpmn2Service.getTaskInputMappings(deploymentUnit.getIdentifier(), processId, "Write a Document" );

ProcessService

• start new process instance
• work with existing one - signal, get details of it, get variables, etc
• work with work items

KModuleDeploymentUnit deploymentUnit = new KModuleDeploymentUnit(GROUP_ID, ARTIFACT_ID, VERSION);

deploymentService.deploy(deploymentUnit);

long processInstanceId = processService.startProcess(deploymentUnit.getIdentifier(), "customtask");

ProcessInstance pi = processService.getProcessInstance(processInstanceId);     

Collection instances = runtimeDataService.getProcessInstances(new QueryContext());

Collection instances = runtimeDataService.getProcessInstanceHistoryActive(processInstanceId, new QueryContext());

List taskSummaries = runtimeDataService.getTasksAssignedAsPotentialOwner("john", new QueryFilter(0, 10));

UserTaskService

• modification of selected properties
• access to task variables
• access to task attachments
• access to task comments

long processInstanceId = 
processService.startProcess(deployUnit.getIdentifier(), "org.jbpm.writedocument");

List<Long> taskIds = 
runtimeDataService.getTasksByProcessInstanceId(processInstanceId);

Long taskId = taskIds.get(0);

userTaskService.start(taskId, "john");
UserTaskInstanceDesc task = runtimeDataService.getTaskById(taskId);

Map<String, Object> results = new HashMap<String, Object>();
results.put("Result", "some document data");
userTaskService.complete(taskId, "john", results);

• CDI - services with CDI wrappers are heavily used (and by that tested) in jbpm console - kie-wb. Entire execution server that comes in jbpm console is utilizing jbpm services over its CDI wrapper.
• Ejb - jBPM provides a sample ejb based execution server (currently without UI) that can be downloaded and deployed to JBoss - it was tested with JBoss but might work on other containers too - it's built with jbpm-services-ejb-impl module
• Spring - a sample application has been developed to illustrate how to use jbpm services in spring based application

Go to application on Openshift Online

• john/john1
• mary/mary1

• it can migrate from one process to another within same kjar
• it can migrate from on process to another across kjars
• it can migrate with node mapping between process versions 

Be careful what you migrate...

• default org.jbpm:Evaluation:1.0 project is used which consists of single process definition - evaluation with version 1
• single process instance is started with this version
• after it has been started, new version of evaluation process is created
• upgraded version is then released as part of org.jbpm:Evaluation:2.0 project with process version 2
• then migration of the active process instance is performed
• results of the process instance migration is the illustrated on process model of active instance and as outcome of the process instance migration

• business users would need to make sure latest versions of processes are in use
• administrators would need to make sure that entire infrastructure is healthy 
• developers would need to make sure all projects are available to their systems

• runtime data - current state of active instances (processes, tasks, jobs)
• audit data - complete view of all states of instances (processes, tasks, events, variables)

Above diagram presents only subset of data model for jBPM and aims at illustrating important parts from maintenance point of view.

JPAAuditLogService auditService = new JPAAuditLogService(emf);
ProcessInstanceLogDeleteBuilder updateBuilder = auditService.processInstanceLogDelete().status(ProcessInstance.STATE_COMPLETED);
int result = updateBuilder.build().execute();

TaskJPAAuditService auditService = new TaskJPAAuditService(emf);
AuditTaskInstanceLogDeleteBuilder updateBuilder = auditService.auditTaskInstanceLogDelete().deploymentId("org.jbpm:HR:1.0");
int result = updateBuilder.build().execute();

ExecutorJPAAuditService auditService = new ExecutorJPAAuditService(emf);
ErrorInfoLogDeleteBuilder updateBuilder = auditService.errorInfoLogDeleteBuilder().dateRangeEnd(new Date());
int result = updateBuilder.build().execute();

RequestInfoLogDeleteBuilder updateBuilder = auditService.requestInfoLogDeleteBuilder().dateRangeEnd(new Date());
result = updateBuilder.build().execute();

• as a services when jBPM is used as BPM platform
• as embedded when jBPM is used as a framework in custom applications

1. When process start it will ask for some details about the person who shall receive award and its details
2. Once instance is started it will go into 'Associate Reviews' user task where associate needs to provide following information:
1. how many peer reviews should be performed
2. how many of them are required to move on without waiting for all to be completed
3. Once this information is available 'Setup Reviews' task will prepare all required structures and populate process variables that will feed multi instance subprocess
4. 'Evaluate Award' task will be created multiple times based on (2.1) selection
5. Each instance of that user task will ask for approval and result of it will be kept in multi instance output collection
6. It has a completion condition that will evaluate result every time one instance of 'Evaluate Award' task is completed as soon as it becomes true it will move on and cancel remaining task instances of 'Evaluate Award'
7. 'Calculate results' will be performed to check what output is collected - if award is approved or rejected and based on that will go to one of the paths.

• reviews_collection
• reviews_results

• process
• forms
• data model

• downloads all required components
• configures services (data source, folder structure, etc)
• bundles the application 
• deploys all applications (jbpm console aka kie workbench and dash builder for BAM)

1. Create data source for jbpm to use - if you want to use default in memory data base that comes with Wildfly server you can skip this step - data source is already defined
1. Create JBoss module for your JDBC driver e.g. org/postgres
2. Edit WILDFLY_HOME/standalone/configuration/standalone-full.xml
3. Define data source for the driver you created e.g. postgres

<xa-datasource jndi-name="java:jboss/datasources/jbpmDS" pool-name="postgresDS" enabled="true" use-java-context="true">
<xa-datasource-property name="ServerName">
      localhost
</xa-datasource-property>
<xa-datasource-property name="PortNumber">
     5432
</xa-datasource-property>
<xa-datasource-property name="DatabaseName">
      jbpm
</xa-datasource-property>
<driver>postgres</driver>
<security>
<user-name>jbpm</user-name>
<password>jbpm</password>
</security>
</xa-datasource>

2. Add application users that will be given access to kie workbench
1. Use WILDFLY_HOME/bin/add_user.sh script (or add_user.bat for windows) to add user(s)
1. Use application realm
2. make sure to assign users one or more of following roles: admin,analyst,user,developer,manager
3. Additionally you can assign your user to any other roles that will be used for human task assignments e.g HR,PM,IT,Accounting for HR example process
4. If you would like to use asset management feature that comes with 6.2 assign your user another role called: kiemgmt
3. Download wildfly distribution of the kie workbench for version 6.2.0.Final from here.
4. Extract the war file into WILDFLY_HOME/standalone/deployments/jbpm-console.war
1. You should have all files from the war file inside jbpm-console.war
5. Configure persistence for jbpm console
1. Edit WILDFLY_HOME/standalone/deployments/jbpm-console.war/WEB-INF/classes/META-INF/persistence.xml file
2. Change JNDI name for the data source
3. Change the hibernate dialect for data base you use
6. Create jbpm-console.war.dodeploy empty file inside WILDFLY_HOME/standalone/deployments directory

1. Shutdown your existing server(s) that run jBPM 6.1 - if there are any running instances
2. Perform data base upgrade
1. jBPM 6.2. comes with upgrade script for commonly used data bases, it can be found as part of jbpm installer/db/upgrade-scripts package or can be taken from gihub.
2. This script contains all data bases so please take only section that applies to your data base (below sql script for postgesql data base as an example)

ALTER TABLE sessioninfo ALTER COLUMN id TYPE bigint;
ALTER TABLE AuditTaskImpl ALTER COLUMN processSessionId TYPE bigint;
ALTER TABLE ContextMappingInfo ALTER COLUMN KSESSION_ID TYPE bigint;
ALTER TABLE Task ALTER COLUMN processSessionId TYPE bigint;

create table DeploymentStore (
    id int8 not null,
    attributes varchar(255),
    DEPLOYMENT_ID varchar(255),
    deploymentUnit text,
    state int4,
    updateDate timestamp,
    primary key (id)
);

alter table DeploymentStore add constraint UK_DeploymentStore_1 unique (DEPLOYMENT_ID);
create sequence DEPLOY_STORE_ID_SEQ;

ALTER TABLE ProcessInstanceLog ADD COLUMN processInstanceDescription varchar(255);
ALTER TABLE RequestInfo ADD COLUMN owner varchar(255);
ALTER TABLE Task ADD COLUMN description varchar(255);
ALTER TABLE Task ADD COLUMN name varchar(255);
ALTER TABLE Task ADD COLUMN subject varchar(255);

-- update all tasks with its name, subject and description
update task t set name = (select shorttext from I18NText where task_names_id = t.id);
update task t set subject = (select shorttext from I18NText where task_subjects_id = t.id);
update task t set description = (select shorttext from I18NText where task_descriptions_id = t.id);

INSERT INTO AuditTaskImpl (activationTime, actualOwner, createdBy, createdOn, deploymentId, description, dueDate, name, parentId, priority, processId, processInstanceId, processSessionId, status, taskId)
SELECT activationTime, actualOwner_id, createdBy_id, createdOn, deploymentId, description, expirationTime, name, parentId, priority,processId, processInstanceId, processSessionId, status, id 
FROM Task;

3. Execute these scripts on your data base - NOTE: make sure that you execute these scripts as schema owner to avoid any permission violation issues one startup
3. Remove jbpm console war file from your application server deployments folder WILDFLY_HOME/standalone/deployments
4. Download wildfly distribution of the kie workbench for version 6.2.0.Final from here.
5. Extract the war file into WILDFLY_HOME/standalone/deployments/jbpm-console.war
1. You should have all files from the war file inside jbpm-console.war
6. Configure persistence for jbpm console
1. Edit WILDFLY_HOME/standalone/deployments/jbpm-console.war/WEB-INF/classes/META-INF/persistence.xml file
2. Change JNDI name for the data source
3. Change the hibernate dialect for data base you use
7. Create jbpm-console.war.dodeploy empty file inside WILDFLY_HOME/standalone/deployments directory - if not already there

• in 6.1 all deployment units that were active on the server were stored in system.git repository - which made it workbench specific and quite hidden - 6.2 comes with db based store for information about active deployments. With that, by default storage of deployment unit info are no more persisted into system.git. Though it can be enabled to be still stored in there by using system property: -Dorg.kie.git.deployments.enabled=true
• in 6.1 all operations of Build & Deploy issued from Project Editor caused auto deploy to runtime which was not always desired, this can be disabled using system property: -Dorg.kie.auto.deploy.enabled=false
• in 6.1 redeploy of same version (regardless if that was concrete version or snapshot) was by default allowed, in 6.2 concrete versions must be explicitly undeployed before they can be redeployed. This can be overridden by system property which will allow redeploy for all versions: -Dorg.kie.override.deploy.enabled=true

• complete installer 
• individual web applications that are container specific so make sure you download one that fits your container (EAP, Wildfly, Tomcat, WebSphere, Weblogic)

1. Direct use of KIE API (KieBase and KieSession) - here you need to configure ExecutorService and add it to kieSession environment under "ExecutorService" key. Once it's there it will process the nodes async way
2. RuntimeManager API - similar to KIE API though you should add ExecutorService as one of environment entires when setting up RuntimeEnvironment
3. jBPM services API - you need to add ExecutorService as attribute of DepoymentService, if you use CDI or EJB that will be injected automatically for you (assuming all dependencies are available to the container)

• supported on any runtime environment (application server, servlet container, standalone)
• allows to decouple requesting the job from executing the job
• allows configurable retry mechanism of failed jobs
• provides search API to look through available jobs
• allows to schedule jobs instead of being executed immediately 

• environment that supports EJB - it will delegate to ejb asynchronous method for execution
• environment that does not support EJB will execute the job in the same thread that polls db

• in EJB environment usually single thread is enough as it is used only for triggering the poll and not actually doing the poll, so number of threads should be kept to minimum and the interval should be used to fine tune the speed of processing of async jobs
• on non EJB environment number of threads should be increased to improve processing power as each thread will be actually doing the work

• jobs are searchable 
• jobs can be retried
• jobs can be scheduled

• main process instance will not finish until all sub process instances are created - depending on number of them might be millisecond or seconds or even minutes (in case of really huge set of sub process instances)
• creation of main process and sub process instances are done in single transaction - all or nothing so if one of the subprocess fails for whatever reason all will be rolled back including main process instance
• it takes time to commit all data into data base after creating all process instances - note that each process instance (and session instance when using per process instance strategy) has to be serialized using protobuf and then send to db as byte array, and all other inserts as well (for process, tasks, history log etc). That all takes time and might exceed transaction timeout which will cause rollback again...

• main process instance will wait only for creating job requests to start all subprocess instances, this is not really starting any process instance yet
• rollback will affect only main process instance and job requests, meaning it is still consistent as unless main process is committed no sub process instances will be created
• subprocess instances are started independently meaning a failure of one instance does not affect another, moreover since this is async job it will be retried and can actually be configured to retry with different delays
• each sub process instance is carried within own transaction which is much smaller and finishes way faster (almost no risk to encounter transaction timeouts) and much less data to be send to data base - just one instance (and session in case of per process instance strategy)

• main process: upon start will create given number of subprocess that will call new process instance (child process instance)
• main process: upon requesting the sub process instance creation (regardless if it's via call activity or async task) it will pass signal name that is build based on some constant + unique (serialized-#{item}) items that represents single entry from multi instance input collection
• main process: will then move on to intermediate catch signal event where name is again same as given to sub process (child) and await it (serialized-#{item})
• sub process: after executing the process it will throw an event via end signal event with signal name given as input parameter when it was started (serialized-#{item}) and use external scope so it will be send via JMS in transactional way - delivered only when subprocess completes (and commits) successfully

Conclusions:

• miprocess-async is the main process that uses async start process command to start child process instance
• miprocess is the main process that uses call activity to start child process instances

• introduction of signal scopes for throwing events
• support for parameterized signal names - both throw and catch signal events

Signal scopes

• process instance scope - is the lowest in the hierarchy of scopes that narrows down the signal to given process instance. That means only catch events within same process instance will be singled, nothing outside of process instance will be affected
• default (ksession) scope - same as in previous versions (and thus called default) that signals only elements known to ksession - behavior will vary depending on what strategy is used 
• singleton - will signal all instances available for this ksession
• per request - will signal only currently processed process instance and those with start signal events
• per process instance - same as per request - will signal only currently processed process instance and those with start signal events
• project scope - will signal all active process instances of given deployment and start signal events (regardless of the strategy)
• external scope - allows to signal both project scope way and cross deployments - for cross deployments it requires to have a process variable called 'SignalDeploymentId' that provides information about what deployment/project should be the target of the signal. It was done on purpose to provide deployment id as doing overall broadcast would have negative impact on performance in bigger environments

• starting up with those that will receive signals - here there is no difference

Intermediate catch signal event

Start signal event

• next those that will throw events with different scopes

Process instance scoped signal

Default (ksession) scoped signal

Project  scoped signal

External scoped signal

Registered External Send Task work item handler for external scope signals

• SignalProcessInstanceId - target process instance id
• SignalDeploymentId - target deployment (project)

declared SignalDeploymentId process variable for external scope signal

• single-project - contains all process definitions that working with same project
• external-project - contains process definition that uses external scope signal (includes a form to enter target deployment id)

Parameterized signal names

1. Introduction to KIE Execution Server and installation notes
2. Use of KIE Server Client to interact with KIE Execution Server
3. KIE Execution Server managed vs unmanaged
4. KIE Execution Server with non java clients
5. KIE Execution Server clustering/scalability

• BRM capability that is what was in 6.2 providing rules execution
• BPM capability that brings jBPM into the picture
• process execution
• task execution
• asynchronous jobs execution

Installation

• -Dorg.drools.server.ext.disabled=true - to disable BRM extension
• -Dorg.jbpm.server.ext.disabled=true - to disable BPM extension

Endpoint:

• http://localhost:8230/kie-server/services/rest/server/queries/processes/definitions

Method:

• GET

When successfully executed you should find single process being available with process if hiring inside container id hr

[INFO]
[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ kie-server-client ---
[INFO] org.kie.server:kie-server-client:bundle:6.3.0-SNAPSHOT
[INFO] +- org.kie:kie-api:jar:6.3.0-SNAPSHOT:compile
[INFO] +- org.kie:kie-internal:jar:6.3.0-SNAPSHOT:compile
[INFO] +- org.kie.server:kie-server-api:jar:6.3.0-SNAPSHOT:compile
[INFO] |  +- org.drools:drools-core:jar:6.3.0-SNAPSHOT:compile
[INFO] |  |  +- org.mvel:mvel2:jar:2.2.6.Final:compile
[INFO] |  |  \- commons-codec:commons-codec:jar:1.4:compile
[INFO] |  +- org.codehaus.jackson:jackson-core-asl:jar:1.9.9:compile
[INFO] |  +- com.thoughtworks.xstream:xstream:jar:1.4.7:compile
[INFO] |  |  +- xmlpull:xmlpull:jar:1.1.3.1:compile
[INFO] |  |  \- xpp3:xpp3_min:jar:1.1.4c:compile
[INFO] |  \- org.apache.commons:commons-lang3:jar:3.1:compile
[INFO] +- org.jboss.resteasy:jaxrs-api:jar:2.3.10.Final:compile
[INFO] |  \- org.jboss.logging:jboss-logging:jar:3.1.4.GA:compile
[INFO] +- org.kie.remote:kie-remote-common:jar:6.3.0-SNAPSHOT:compile
[INFO] +- org.codehaus.jackson:jackson-xc:jar:1.9.9:compile
[INFO] +- org.codehaus.jackson:jackson-mapper-asl:jar:1.9.9:compile
[INFO] +- org.slf4j:slf4j-api:jar:1.7.2:compile
[INFO] +- org.jboss.spec.javax.jms:jboss-jms-api_1.1_spec:jar:1.0.1.Final:compile
[INFO] +- com.sun.xml.bind:jaxb-core:jar:2.2.11:compile
[INFO] \- com.sun.xml.bind:jaxb-impl:jar:2.2.11:compile

<project xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://maven.apache.org/POM/4.0.0" xsi:schemalocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelversion>4.0.0</modelversion>
<groupid>org.jbpm.test</groupid>
<artifactid>kie-server-test</artifactid>
<version>0.0.1-SNAPSHOT</version>

<dependencies>
<dependency>
<groupid>org.kie</groupid>
<artifactid>kie-internal</artifactid>
<version>6.3.0-SNAPSHOT</version>
</dependency>
<dependency>
<groupid>org.kie.server</groupid>
<artifactid>kie-server-client</artifactid>
<version>6.3.0-SNAPSHOT</version>
</dependency>
<dependency>
<groupid>ch.qos.logback</groupid>
<artifactid>logback-classic</artifactid>
<version>1.1.2</version>
</dependency>
</dependencies>

boolean deployContainer = true;
KieContainerResourceList containers = kieServicesClient.listContainers().getResult();
// check if the container is not yet deployed, if not deploy it
if (containers != null) {
    for (KieContainerResource kieContainerResource : containers.getContainers()) {
        if (kieContainerResource.getContainerId().equals(containerId)) {
            System.out.println("\t######### Found container " + containerId + " skipping deployment...");
            deployContainer = false;
            break;
        }
    }
}
// deploy container if not there yet        
if (deployContainer) {
    System.out.println("\t######### Deploying container " + containerId);
    KieContainerResource resource = new KieContainerResource(containerId, new ReleaseId("org.jbpm", "HR", "1.0"));
    kieServicesClient.createContainer(containerId, resource);
}

// query for all available process definitions
QueryServicesClient queryClient = kieServicesClient.getServicesClient(QueryServicesClient.class);
List<ProcessDefinition> processes = queryClient.findProcesses(0, 10);
System.out.println("\t######### Available processes" + processes);

ProcessServicesClient processClient = kieServicesClient.getServicesClient(ProcessServicesClient.class);
// get details of process definition
ProcessDefinition definition = processClient.getProcessDefinition(containerId, processId);
System.out.println("\t######### Definition details: " + definition);

• name - of type string 
• age - of type integer

// start process instance
Map<String, Object> params = new HashMap<String, Object>();
params.put("name", "john");
params.put("age", 25);
Long processInstanceId = processClient.startProcess(containerId, processId, params);
System.out.println("\t######### Process instance id: " + processInstanceId);

UserTaskServicesClient taskClient = kieServicesClient.getServicesClient(UserTaskServicesClient.class);
// find available tasks
List<TaskSummary> tasks = taskClient.findTasksAssignedAsPotentialOwner(user, 0, 10);
System.out.println("\t######### Tasks: " +tasks);

// complete task
Long taskId = tasks.get(0).getId();

taskClient.startTask(containerId, taskId, user);
taskClient.completeTask(containerId, taskId, user, null);

List<NodeInstance> completedNodes = queryClient.findCompletedNodeInstances(processInstanceId, 0, 10);
System.out.println("\t######### Completed nodes: " + completedNodes);

// at the end abort process instance
processClient.abortProcessInstance(containerId, processInstanceId);

ProcessInstance processInstance = queryClient.findProcessInstanceById(processInstanceId);
System.out.println("\t######### ProcessInstance: " + processInstance);

// work with rules
List<GenericCommand> commands = new ArrayList<GenericCommand>();
BatchExecutionCommandImpl executionCommand = new BatchExecutionCommandImpl(commands);
executionCommand.setLookup("defaultKieSession");

InsertObjectCommand insertObjectCommand = new InsertObjectCommand();
insertObjectCommand.setOutIdentifier("person");
insertObjectCommand.setObject("john");

FireAllRulesCommand fireAllRulesCommand = new FireAllRulesCommand();

commands.add(insertObjectCommand);
commands.add(fireAllRulesCommand);

RuleServicesClient ruleClient = kieServicesClient.getServicesClient(RuleServicesClient.class);
ruleClient.executeCommands(containerId, executionCommand);
System.out.println("\t######### Rules executed");

• containers
• processes
• tasks
• rules

• deploy container
• undeploy container
• start container
• stop container

• kieserver (with password kieserver1!) that will be used to communicate between KIE Server and controller, that user must be member of following roles:
• kie-server
• rest-all
• either add following roles to kieserver user or create another user that will be used to logon to KIE workbench to manage KIE Execution Servers
• admin
• rest-all

• create KIE Execution Server definition in the controller
• specified identifier (first-kie-server) and name
• create new container in the KIE Execution Server definition (org.jbpm:HR:1.0)
• configure KIE Execution Server to be managed by specifying URL to the controller via system property:
• -Dorg.kie.server.controller=http://localhost:8080/kie-wb/rest/controller
• -Dorg.kie.server.id=first-kie-server (this is extremely important that this id matches one created in first step in the KIE Workbench)
• start kie server and observe controller's log to see notification that kie server has connected to it
• start container in controller and observe it being automatically started on KIE Execution Server instance
• shutdown KIE Execution Server and observe logs and UI with updated status of kie server being disconnected
• illustrates various manage options in controller and it effect on KIE Execution Server instance.

• copy app folder that exists in jbpm-angular-js into your wildfly installation:

• rename the folder from app to app.war

• look at available containers 
• look at available process definitions
• examine details of process definition we are going to start an instance of
• start process instance with variables (both simple type and custom type)
• examine process instance details
• work with user tasks
• list available user tasks for logged in user
• examine details of selected task
• claim task
• start task
• complete task with variables (complex type)

• first 'Review and Register' is used for gathering data from assigned user
• second 'Show details' is just for the demo purpose to illustrate that process variable was properly updated with data given in first task

• person - that is of type org.jbpm.test.Person and consists of following fields
• name - String
• address - String
• age - Integer
• registered - Boolean
• note - String

• Simple class name = Person
• Fully qualified class name = org.jbpm.test.Person

• rename kie-wb-distribution-wars-6.3.0.Final-wildfly8.war to kie-wb.war
• rename kie-server-6.3.0.Final-ee7.war to kie-server.war

• -Dorg.kie.server.id=wildfly-kieserver 
• -Dorg.kie.server.location=http://localhost:8080/kie-server/services/rest/server 
• -Dorg.kie.server.controller=http://localhost:8080/kie-wb/rest/controller

Configure users

<tomcat-users>
<role rolename="admin"/>
<role rolename="analyst"/> 
<role rolename="user"/>
<role rolename="kie-server"/>

<user username="workbench" password="workbench1!" roles="admin,kie-server"/>
<user username="kieserver" password="kieserver1!" roles="kie-server"/>  
</tomcat-users>

Configure system properties

Launching the server

• disable BRM: -Dorg.drools.server.ext.disabled=true
• disable BPM: -Dorg.jbpm.server.ext.disabled=true

• Next modify persistence.xml that resides inside workbench war file. Extract the kie-wb.war file into directory with same name and in same location (WILDFLY_HOME/standalone/deployments). 
• Then navigate to kie-wb.war/WEB-INF/classes/META-INF
• Edit persistence.xml file and change following elements
• jta-data-source to point to the newly created data source (JNDI name) for your data base
• hibernate.dialect to hibernate supported dialect name for you data base

• -Dorg.kie.server.persistence.ds=java:jboss/datasources/jbpmDS
• -Dorg.kie.server.persistence.dialect=org.hibernate.dialect.MySQL5Dialect

• REST
• JMS

• Drools extension
• kie-server-services-drools
• kie-server-rest-drools
• jBPM extension
• kie-server-services-jbpm
• kie-server-rest-jbpm
• jBPM UI extension
• kie-server-services-jbpm-ui
• kie-server-rest-jbpm-ui

• Drools extension
• org.drools.server.ext.disabled = true
• jBPM extension
• org.jbpm.server.ext.disabled = true
• jBPM UI extension
• org.jbpm.ui.server.ext.disabled = true

Why extensions are needed?

Let's extend KIE Server capabilities

• id is container identifier
• ksessionId is name of the ksession within container to be used

<properties>
<version.org.kie>6.4.0-SNAPSHOT</version.org.kie>
</properties>

<dependencies>
<dependency>
<groupId>org.kie</groupId>
<artifactId>kie-api</artifactId>
<version>${version.org.kie}</version>
</dependency>
<dependency>
<groupId>org.kie</groupId>
<artifactId>kie-internal</artifactId>
<version>${version.org.kie}</version>
</dependency>

<dependency>
<groupId>org.kie.server</groupId>
<artifactId>kie-server-api</artifactId>
<version>${version.org.kie}</version>
</dependency>
<dependency>
<groupId>org.kie.server</groupId>
<artifactId>kie-server-services-common</artifactId>
<version>${version.org.kie}</version>
</dependency>
<dependency>
<groupId>org.kie.server</groupId>
<artifactId>kie-server-services-drools</artifactId>
<version>${version.org.kie}</version>
</dependency>

<dependency>
<groupId>org.kie.server</groupId>
<artifactId>kie-server-rest-common</artifactId>
<version>${version.org.kie}</version>
</dependency>

<dependency>
<groupId>org.drools</groupId>
<artifactId>drools-core</artifactId>
<version>${version.org.kie}</version>
</dependency>
<dependency>
<groupId>org.drools</groupId>
<artifactId>drools-compiler</artifactId>
<version>${version.org.kie}</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.2</version>
</dependency>

</dependencies>

Implement KieServerApplicationComponentsService

• it is called by all extensions and thus it provides extension name so custom implementations can decide if this extension is for it or not
• supported type - either REST or JMS - in our case it will be REST only
• services - dedicated services to given extensions that can be then used as part of custom extension - usually these are engine services

public class CusomtDroolsKieServerApplicationComponentsService implements KieServerApplicationComponentsService {

    private static final String OWNER_EXTENSION = "Drools";

    public Collection<Object> getAppComponents(String extension, SupportedTransports type, Object... services) {
        // skip calls from other than owning extension
        if ( !OWNER_EXTENSION.equals(extension) ) {
            return Collections.emptyList();
        }

        RulesExecutionService rulesExecutionService = null;
        KieServerRegistry context = null;

        for( Object object : services ) { 
            if( RulesExecutionService.class.isAssignableFrom(object.getClass()) ) { 
                rulesExecutionService = (RulesExecutionService) object;
                continue;
            } else if( KieServerRegistry.class.isAssignableFrom(object.getClass()) ) {
                context = (KieServerRegistry) object;
                continue;
            }
        }

        List<Object> components = new ArrayList<Object>(1);
        if( SupportedTransports.REST.equals(type) ) {
            components.add(new CustomResource(rulesExecutionService, context));
        }

        return components;
    }

}

Implement REST resource

@Path("server/containers/instances/{id}/ksession")
public class CustomResource {

    private static final Logger logger = LoggerFactory.getLogger(CustomResource.class);

    private KieCommands commandsFactory = KieServices.Factory.get().getCommands();

    private RulesExecutionService rulesExecutionService;
    private KieServerRegistry registry;

    public CustomResource() {

    }

    public CustomResource(RulesExecutionService rulesExecutionService, KieServerRegistry registry) {
        this.rulesExecutionService = rulesExecutionService;
        this.registry = registry;
    }

    @POST
    @Path("/{ksessionId}")
    @Consumes({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON})
    @Produces({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON})
    public Response insertFireReturn(@Context HttpHeaders headers, 
            @PathParam("id") String id, 
            @PathParam("ksessionId") String ksessionId, 
            String cmdPayload) {

        Variant v = getVariant(headers);
        String contentType = getContentType(headers);

        MarshallingFormat format = MarshallingFormat.fromType(contentType);
        if (format == null) {
            format = MarshallingFormat.valueOf(contentType);
        }
        try {    
            KieContainerInstance kci = registry.getContainer(id);

            Marshaller marshaller = kci.getMarshaller(format);

            List<?> listOfFacts = marshaller.unmarshall(cmdPayload, List.class);

            List<Command<?>> commands = new ArrayList<Command<?>>();
            BatchExecutionCommand executionCommand = commandsFactory.newBatchExecution(commands, ksessionId);

            for (Object fact : listOfFacts) {
                commands.add(commandsFactory.newInsert(fact, fact.toString()));
            }
            commands.add(commandsFactory.newFireAllRules());
            commands.add(commandsFactory.newGetObjects());

            ExecutionResults results = rulesExecutionService.call(kci, executionCommand);

            String result = marshaller.marshall(results);


            logger.debug("Returning OK response with content '{}'", result);
            return createResponse(result, v, Response.Status.OK);
        } catch (Exception e) {
            // in case marshalling failed return the call container response to keep backward compatibility
            String response = "Execution failed with error : " + e.getMessage();
            logger.debug("Returning Failure response with content '{}'", response);
            return createResponse(response, v, Response.Status.INTERNAL_SERVER_ERROR);
        }

    }
}

Make it discoverable

Usage example

• init method
• destroy method

public interface KieServerExtension {

    boolean isActive();

    void init(KieServerImpl kieServer, KieServerRegistry registry);

    void destroy(KieServerImpl kieServer, KieServerRegistry registry);

    void createContainer(String id, KieContainerInstance kieContainerInstance, Map<String, Object> parameters);

    void disposeContainer(String id, KieContainerInstance kieContainerInstance, Map<String, Object> parameters);

    List<Object> getAppComponents(SupportedTransports type);

<T> T getAppComponents(Class<T> serviceType);

    String getImplementedCapability();

    List<Object> getServices();

    String getExtensionName();

    Integer getStartOrder();
}

• each incoming request is single line, so make sure before submitting anything to it make sure it's single line
• there is a need to pass container id in this single line so this handler expects following format:
• containerID|payload
• response is set the way it is produced by marshaller and that can be multiple lines
• handlers allows "stream mode" that allows to send commands without disconnecting from KIE Server session. to be able to quit the stream mode - send either exit or quit