Wednesday, May 27, 2015

Enabling debug logging of jaggery files when used with other products

You might come across scenarios where you have jaggery implementation in your other WSO2 products. (ex: bpmn- explorer in BPS) . So , when enabling debug logs, there are two things you have to do .

1. Go to jaggery.conf and change log level.

  "logLevel": "debug"

2. Go to management console of your WSO2 product.
   2.1 Go to Configure -> Logging
   2.2 Under   Configure Log4J Appenders    change   threshold value to DEBUG .

Sunday, May 24, 2015

BPEL partner links simplified for java developers

If you have come across the need to create a BPEL process invoking a web service, you surely had to deal with partner links, port types and many other terminologies. Until you get the hang of it , it is somewhat confusing on what they actually do. So this is a simple explanation on how you can keep in mind the usage of these properties so you know when and how to use them.

Partner links are used to link all the external web services that a bpel process deals with. It's somewhat a reference/declaration , so that you can define how and where our bpel process would interact with a given web service.  The basic structure of a partner link is as follows.

    Partner Link
      --- Partner Link Type
                    ---  Port Type
                         ---  operation

for example a sample partner link would like like  this.
<plink:partnerLinkType name="loanProcessorEjbPartner">

    <plink:role name="loanProcessorEJB"
                portType="ns:LoanProcessorEJBSEI">

    </plink:role>

  </plink:partnerLinkType>
As a Java developer, it will be much easier for you to understand this definition, if you think of each section in java terminology. Now try to think of the structure with the meanings of terminologies in red.

Partner Link
      --- Partner Link Type ( Abstract class)
                    ---  Port Type (Interface)
                         ---  operation (methods defined in the interface)

Wasn't that much easier? A partner link type is something like an abstract class, that would implement the interface (port type) ,which contains the method (operation). So basically we are creating a relationship with a partner link by saying, at this invoke of a web service, we will be executing this certain operation defined in this interface, by using this abstract class.

Another important point is the partner role that will be defined. This partner role will tell if it's a service provider or a service consumer. So if you define a 'myRole' it will mean that the  bpel process you created will act as the service provider and vice versa.

Once you grasp these concepts, invoking a web service and creating a bpel process is not going to be hard. In fact, you could look into [1] which explains how to invoke a web service with a bpel process using WSO2 BPS.  Also you could go through [2] to gain more information on how BPEL works.

[1] http://wso2.com/library/tutorials/2011/04/using-carbon-studio-model-wsbpel-process-using-bpel-editor/

[2]BPEL for Java Developers - ActiveVOS

Monday, May 18, 2015

Cron style file transfer with WSO2 ESB File Connector

Given a requirement where you would need to perform a file transfer as a cron job (ex: transfer files during weekends only) , you will have to use a scheduled task. But the default VFS transport mechanism would not work with a scheduled task. Therefore, you should use file connector to perform the file transfers. [1]

1.First of all you need to download file connector from wso2 store.
2.  Go through [2] and enable the file connector zip, downloaded from step 1.
3.Now that you have enabled File connector, you can have a sample proxy configuration like below. (Note: I have used ESB 4.8.0 )

proxy name="SampleProxy" transports="https http" startOnLoad="true" trace="disable">
<target>
<inSequence>
<property name="filelocation" expression="json-eval($.filelocation)"/>
<property name="file" expression="json-eval($.file)"/>
<property name="newfilelocation" expression="json-eval($.newfilelocation)"/>
<property name="filebeforeprocess" expression="json-eval($.filebeforeprocess)"/>
<property name="fileafterprocess" expression="json-eval($.fileafterprocess)"/>
<fileconnector.move>
<filelocation>{$ctx:filelocation}</filelocation>
<file>{$ctx:file}</file>
<newfilelocation>{$ctx:newfilelocation}</newfilelocation>
<filebeforeprocess>{$ctx:filebeforeprocess}</filebeforeprocess>
<fileafterprocess>{$ctx:fileafterprocess}</fileafterprocess>
</fileconnector.move>
<respond/>
</inSequence>
</target>
<description/>
</proxy>


4. Next add a schedule task [3], that would perform this proxy according to given cron expression.
    You can give below values for the schedule task properties.

Task Name : SampleInjectToSequenceTask
Task group : synapse.simple.quartz
Task Implementation :org.apache.synapse.startup.tasks.MessageInjector
Trigger Type : Cron
Cron : * * * * 6-0 ? (add your specific cron expression)
By clicking 'Load Task Properties' button(near Task Implementation) you can add below property values.
injectTo : proxy
proxyName : SampleProxy
message (xml): <m0:getQuote xmlns:m0="http://services.samples">
<m0:request>
<m0:symbol>IBM</m0:symbol>
</m0:request>
</m0:getQuote> 

5. Create a sample JSON input file like below. (sampleFileConnector.xml )

{
    "filelocation":"file:///Users/himasha/Desktop/in/",
    "file":"fileSample.txt",
    "newfilelocation":"file:///Users/himasha/Desktop/out/",
    "filebeforeprocess":"file:///Users/himasha/Desktop/before/",
    "fileafterprocess":"file:///Users/himasha/Desktop/after/"
}

6. Use this curl command to test your proxy configuration.
url -v -X POST  -d @Desktop/sampleFileConnector.xml -H "Content-type: application/json" http://localhost:8280/services/SampleProxy

7. You can look into [4] to get more information on different operations/ properties that are available in File Connector.  Also go through [5] to refer more on WSO2 ESB connectors.

 [1] https://docs.wso2.com/display/ESBCONNECTORS/File+Connector
[2] hhttps://docs.wso2.com/display/ESB481/Managing+Connectors+in+Your+ESB+Instance
[3]  https://docs.wso2.com/display/ESB481/Adding+and+Scheduling+Tasks#AddingandSchedulingTasks
[4] https://docs.wso2.com/display/ESBCONNECTORS/Working+with+the+File+Connector
[5] https://docs.wso2.com/display/ESBCONNECTORS/WSO2+ESB+Connectors+Documentation

Wednesday, May 13, 2015

Common WSO2 ESB endpoint format error

When invoking an API which includes building soap messages , you must've come across this error.

First Element must contain the local name, Envelope , but found faultstring

This is happening when the server is not returning the expected xml response format. For example, if you have an endpoint like [1] where soap format 11 is declared , but the server returns a soap12 format, you might get an error like above.

[1] <endpoint xmlns="http://ws.apache.org/ns/synapse" name="StudentServiceEndpoint">
    <address uri="http://localhost:9764/services/StaffService" format="soap11"/>
</endpoint>


The cause for this is Axis2 dispatches the message based on Request URI based on different options like below.
1.Request URI Operation based
2.SOAP Action based
3.SOAP MessageBody based

So if the system can't  find any of the options to dispatch the request to correct endpoint, axis2 will throw an error.

Wednesday, May 6, 2015

Installing account lockout feature in WSO2 API Manager Store

This feature is available in Identity Server. Therefore you can install the identity-mgt feature to API Manager and configure it. Follow given steps to install the feature.

1. Log in to API manager management console and go to configure -> feature -> feature management.

2. Add repository http://dist.wso2.org/p2/carbon/releases/turing/ and click on 'Find Features'.

3.Once features are listed you can select Identity Management feature and install it.

4. Go to <APIM_HOME>/repository/conf/security/identity-mgt.properties and add below configuration.

Identity.Listener.Enable=true

Notification.Sending.Enable=true

Notification.Expire.Time=7200

Notification.Sending.Internally.Managed=true

Authentication.Policy.Enable=true

Authentication.Policy.Account.Lock.On.Failure=true

Authentication.Policy.Account.Lock.On.Failure.Max.Attempts=2

Authentication.Policy.Account.Lock.Time=2

5. Restart server.

Passing accept headers to fault sequence

When it comes to writing custom fault sequences, there are situations where you need to access values of different properties/ headers within your in sequence. One such requirement is to access the value of an accept header within your fault sequence. Usually , such axis2 based values are not preserved in fault sequence. Therefore you need to use 'operation' scope.

Below example code explains how you can retrieve accept header value in your fault sequence. In your in sequence, you can save header value to a property like below.

          <header name="Accept" value="image/jpeg" scope="transport"/>
         
            <property name="accept" expression="$trp:Accept" scope="operation"/>


Next in your in sequence you can access that created property like following.

 <property name="testheader" expression="get-property('operation', 'accept')"/>

You can get more information regarding this scope in [1]

[1] https://docs.wso2.com/display/ESB481/XPath+Extension+Functions#XPathExtensionFunctions-operationscope