Disruptive technology

Disruptive technology = > Order of magnitude cheaper , order of magnitude lower quality, order of magnitude lower margin captured by the vendor

How to increase the number of processes allowed in oracle database.

Log in as sys

$ sqlplus sys as sysdba;

Enter the passed for sys when prompted.

If your application makes many connections and the number of processes allowed to be created by the oracle db is smaller than that, you will get the error

ORA-12519: TNS:no appropriate service handler found

To solve this issue, first view the number of processes allowed by oracle.

SQL> select * from v$resource_limit where resource_name = 'processes';

If you are using oracle express edition, this value would be 40.

Now increase number of allowed the processes

SQL>alter system set processes=300 scope=spfile;
SQL>shutdown immediate;
SQL>startup

How to log from within a BPEL process

There are multiple ways to log information from a BPEL process to the server logfile.

One options is to write your own extension activity and use it to log information to the log where necessary. However, there is a simple and easy way to write logs without writing your own extension. That is to use the E4X extension activity.

In order to use E4X extension within your bpel process, follow the following steps.

1. Add xpath 2.0 namespaces to the process definition.

queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath2.0"
expressionLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath2.0"

2. Define e4x as an extension.

<bpel:extensions>
  <bpel:extension namespace="http://ode.apache.org/extensions/e4x" mustUnderstand="yes"/>
</bpel:extensions>

3. Include the e4x extension operation where you want to log information.

   <bpel:assign validate="no" name="AssignE4X">
      <bpel:extensionAssignOperation>
         <js:snippet xmlns:js="http://ode.apache.org/extensions/e4x">
           <![CDATA[ print(“My Log message from bpel process");  ]]>
         </js:snippet>
       </bpel:extensionAssignOperation>
   </bpel:assign>

How to implement your own task UI on top of WSO2 BPS Human Task Engine

Human Tasks is a specification which helps us define tasks performed by human beings. From an SOA point of view, we can view a Human Task as a service implemented by a human being.

WSO2 Business process server (WSO2 BPS ) 3.0.0 version includes an evolving initial implementation of a Human Task Engine. It provides the basic human tasks functionality such as the ability to define human tasks and notifications, timer events and escalations, and the people assignments.

Also within its implementation, WSO2 BPS provides its own task UI. However, as this task UI is included within the Administrative console of the server, we do not encourage one to use it. Instead, what we expect from a serious human tasks user is to build his own task ui using what ever the user interface implementation methodology that is used within the organization. This could be done using technologies such as JSP, PHP ect. As long as you have a way of sending out soap messages, you can build your own task ui. In the following section, I will describe how to build your own task UI.

In order to  implement your own task UI, you need to understand how the Human task engine works.

A human task package will include at least one WSDL file which defines the ‘task service’ which is the service implemented by human being. In order to create a task, this task service should be invoked by an external party. This external party can either be an external web service invoker or a bpel process using Bpel4People extension activity.  When a task instance is created, it will have its own unique task id which will be returned to the task invoker. Additionally, this task id can be obtained by using the simpleQuery operation which returns a list of tasks. When your perform operations on the task, this unique task id is used to identify the specific task instance among the many task instances residing within the task engine.

Human Task specification describes the human tasks client api in detail in Chapter 7 Programming interfaces. [1] http://docs.oasis-open.org/bpel4people/ws-humantask-1.1-spec-cs-01.html

WSO2 BPS human tasks implementation also implements the same API. In order to successfully call this task client api, first we need to find out the admin service interface for it.

Step1.

Go to carbon.xml located in <BPS_HOME>/repository/conf/ directory.

Change the setting <HideAdminServiceWSDLs>true</HideAdminServiceWSDLs> to false.

<HideAdminServiceWSDLs>false</HideAdminServiceWSDLs>

Now start the bps server with option –DosgiConsole.

Once the server is fully started, enter to go to osgi console.

Now type listAdminServices in osgi console.

osgi> listAdminServices

This will list down all admin services.

Our interested endpoint is

HumanTaskClientAPIAdmin,https://<ip>:9443/services/HumanTaskClientAPIAdmin/

Usually, when you try ?wsdl on this endpoint, the wsdl will appear. However, there is an issue with the HumanTaskClientApi WSDL. Hence please download the wsdls from following location. http://people.wso2.com/~nandika/htwsdl/

Step2.

Create a soap ui project from the human_task_api.wsdl. Your soap ui project will show the task operations available as following.

Now, we can use this soapui client to query the human task client api to obtain the necessary information about tasks. By this method, we can explore the available operations to build our own custom ui.

However, this service is an authenticated service. Therefore, first you need to obtain the session cookie returned by the authentication admin login request and set it as an http header in the soap ui. Please refer to my previous blog on how to set the session cookie.

http://nandikajayawardana.blogspot.com/2012/10/how-to-invoke-admin-services-with-soapui.html

Step 3.

Do the authentication admin login request and copy the returned session cookie.

Using the session cookie, send the simple query request with Filter ALL_TASKS to obtain a list of all tasks.

Use the following soap message for that.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="http://docs.oasis-open.org/ns/bpel4people/ws-humantask/api/200803" xmlns:ns1="http://docs.oasis-open.org/ns/bpel4people/ws-humantask/types/200803">
   <soapenv:Header/>
   <soapenv:Body>
      <ns:simpleQuery>
         <ns:simpleQueryInput>
            <ns1:simpleQueryCategory>ALL_TASKS</ns1:simpleQueryCategory>
         </ns:simpleQueryInput>
      </ns:simpleQuery>
   </soapenv:Body>
</soapenv:Envelope>

This should return a list of currently available tasks.

Now iterate though the task list and use load task method with the task id to load individual tasks.
Use following soap message.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="http://docs.oasis-open.org/ns/bpel4people/ws-humantask/api/200803">
   <soapenv:Header/>
   <soapenv:Body>
      <ns:loadTask xmlns:ns="http://docs.oasis-open.org/ns/bpel4people/ws-humantask/api/200803">
         <ns:identifier>8405</ns:identifier>
      </ns:loadTask>
   </soapenv:Body>
</soapenv:Envelope>

This would return all information about the given task.



After you have obtained this data, you can use operations such as start, stop , claim, complete ect with the task id and corresponding xml message.

For example, start task request would look like the following.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="http://docs.oasis-open.org/ns/bpel4people/ws-humantask/api/200803">
   <soapenv:Header/>
   <soapenv:Body>
      <ns:start xmlns:ns="http://docs.oasis-open.org/ns/bpel4people/ws-humantask/api/200803">
         <ns:identifier>8405</ns:identifier>
      </ns:start>
   </soapenv:Body>
</soapenv:Envelope>

Additionally, you can refer to the human task ui jsp pages of BPS to get more details.
https://svn.wso2.org/repos/wso2/carbon/platform/branches/4.0.0/components/business-processes/humantask/org.wso2.carbon.humantask.ui/4.0.5/src/main/resources/web/humantask

Developing a Business Process with a Correlation Set Using WSO2 Developer Studio

In the example, we will explore how to use correlation sets to route a message to an existing instance of a business process. We are going to use the simplest possible BPEL process. An Echo Process which will accept the same request message twice. Following is a sequence diagram for the sample use case.


Since the second EchoRequest can either create a new instance of the EchoProcess or be routed to a previously created instance of EchoProcess, we require a correlation set.

CorrelationSet ,Property and property Alias.

A CorrelationSet is some unique set of values contained in the message that will be used by the process engine to select the correct process instance to send the message to. Correlation is done between two or more messages. A CorrelationSet can contain one or more properties.
Once we define a correlation property, we have to define the corresponding values in each of the messages we expect to correlate. These corresponding values are called Property Aliases.

Lets create the process using WSO2 Developer studio

Step1. Create the business process.


 

Click next and client finish to create the BPEL project.
2. Generate a business process with the synchronous business process template.

3. Drag and drop receive, assign and reply activities such that we will get the following process

4. Click on the Assign activity and assign ‘input’ from input variable to ‘result’ from output variable.

5. Similarly, complete the next receive, assign and reply activity by using the same partner link
‘client’ .Now we have completed the business of the process logic. Now we need to add the correlation set to two receive activities.

6. Create a correlation set by clicking on the ‘+’ sign next to Correlation Sets

7. Select the correlation set and select properties and click on Add.

8. We will get the Select property wizard. Click on New.

9. Give a name to our correlation property.

10. Select the data type for our correlation property. We have selected is here as a ‘Simple Type’. Click Browse. Now we have to select the data type from xml schema types. Select string as our type.

Now a pop up box will appear and asks for the prefix to be used to the xml schema namespace. Give the prefix as ‘xsd’.

11. Click on the new button next to Alias to define property alias.

 

12. Click on browse and select the message type and input string for query.

13. Now we have finished defining the correlation set, property and alias. Note that we have selected only one alias here because, we are using the same message for both receive activities. Now we have to add the correlation set to the receive activities. On the first receive activity, which creates the process instance, we will initialize the correlation set. On the next, receive activity; we do not need to initialize. Click on the receive activity, and go to properties, click add and select the correlation set. Since we have only one correlation set, it will appear. On the initialize section select yes.

On the next correlation activity, set initiation to no.
14. Next, generate the deployment descriptor.

Next select all files related to the project and create a zip package.  Upload the bpel package.  One the process is deployed successfully; we can use tryit to send a request to the process. 

Now browse to instance view for this process. Now the instance has complete up to reply activity and
is waiting on the next receive activity. Under the correlation properties: you can see the value we sent in the request.

 14. Now send the same request from tryit again.  Now the process instance has gone to the completed instance.  You can follow the same steps we used here to add correlation sets to any asynchronous business process you implement. Correlation sets can be added to ‘receive’, ‘invoke’ and ‘pick’ activities.