If the question is How to call AS400 DB2 RPG calls from WSO2 ESB, then the answer is PCML connector. It is a very convenient way to call RPG calls, as it can be done by doing only few configurations, with zero code. The rest is handled by WSO2 ESB!!.
A bit about RPG
RPG stands for Report Program Generator, and it a high level programing language specific for IBM AS400, More on RPG.
PCML Connector
A complete guide is in WSO2 ESB Connector documentation.
In order to call an RPG there are only few steps.
1. Save .pcml file in the registry. This should contain the RPG library string and the parameters (both input and output). When the parameters are defined the parameter type, length should be matched as in IBM documentation. For an example, if the parameter is a String value then the type should be char and the length should be matched to the length of the String.
2. pcml.init config in the calling synapse config should be defined. Under that, the server ip, username, password should be defined
3. The payload factory mediator can be defined to pass the payload with the parameters.
4. The pcml.call config to configure the .pcml file location and to call the PCML connector to get the things done.
Sunday, September 3, 2017
Thursday, August 3, 2017
Benefits of WSO2 ESB
WSO2 ESB is a cloud enabled, 100% open source integration solution which is a standards-based messaging engine that provides the value of messaging
without writing code. Instead of having your heterogeneous enterprise applications and systems, which are using various standards and protocols, communicate point-to-point with each other, you can simply integrated with WSO2 ESB, which handles transforming and routing
the messages to the appropriate destinations.
It also compromises of
- data integration capabilities, eliminating the need to use a separate data services server for your integration processes.
- managing long-running, stateful business processes.
- analytics capabilities for comprehensive monitoring
- message brokering capabilities that can be used for reliable messaging
- capabilities to run microservices for your integration flows.
Other than those key features, some benefits of having WSO2 ESB are,
Find more on WSO2 ESB from:
http://wso2.com/library/articles/2017/07/what-is-wso2-esb/
It also compromises of
- data integration capabilities, eliminating the need to use a separate data services server for your integration processes.
- managing long-running, stateful business processes.
- analytics capabilities for comprehensive monitoring
- message brokering capabilities that can be used for reliable messaging
- capabilities to run microservices for your integration flows.
Other than those key features, some benefits of having WSO2 ESB are,
- Enables communication among various heterogeneous applications and systems
- 100% open source, lightweight, and high performance
- Support for open standards such as REST, SOAP, WS-*
- Support for domain specific solutions (SAP, FIX, HL7)
- Support message format transformation
- Supports message routing
- Supports message enrichment
- 160+ Connectors (A ready made tool that can be used to connect to public web APIs) such as Salesforce, JIRA, Twitter, LDAP, Facebook and more)
- Supports wider range of integration scenarios, known as EIP patterns
- Having Scalable and extensible architecture
- Easy to configure and re-use, tooling support via Developer Studio, which is an eclipse based tool for artifact design
- Equipped with ESB analytics, for real time monitoring
Find more on WSO2 ESB from:
http://wso2.com/library/articles/2017/07/what-is-wso2-esb/
Tuesday, May 23, 2017
WSO2 ESB Message Flow
WSO2 ESB is a lightweight open source and high performing ESB. It is built on Synpase, which acts as the mediation engine.
This blog post describes the message flow of ESB at the synapse level from the client to backend and then backend to client.
To trace the message flow we can deploy a proxy service and invoke that,
<?xml version="1.0" encoding="UTF-8"?>
<proxy xmlns="http://ws.apache.org/ns/synapse"
name="TestProxy"
startOnLoad="true"
statistics="disable"
trace="disable"
transports="https,http">
<target>
<inSequence>
<log/>
<send>
<endpoint>
<address uri="http://www.mocky.io/v2/5924085b100000771e003629"/>
</endpoint>
</send>
</inSequence>
</target>
<description/>
</proxy>
When a request comes from the client side, at the synapse level, it first hits the receive method in ProxyServiceMessageReceiver. This is the message flow in the request flow,
org.apache.synapse.core.axis2.ProxyServiceMessageReceiver.receive
at this level having the axis2 message context
org.apache.synapse.core.axis2.MessageContextCreatorForAxis2.getSynapseMessageContext
get the synapse message context out of it
org.apache.synapse.core.axis2.ProxyService.registerFaultHandler
fault handler is registered for the proxy service
org.apache.synapse.mediators.base.SequenceMediator.mediate
call the mediate method in the in-sequence
org.apache.synapse.mediator.AbstractListMediator.mediate
iterates through mediators in the in-sequence
org.apache.synapse.mediators.builtin.SendMediator.mediate
org.apache.synapse.endpoints.AddressEndpoint.send
org.apache.synapse.core.axis2.Axis2Sender.sendOn
org.apache.synapse.core.axis2.Axis2FlexibleMEPClient.send
org.apache.synapse.core.axis2.SynapseCallbackReceiver.handleMessage
org.apache.synapse.core.axis2.Axis2SynapseEnvironment.injectMessage
org.apache.synapse.mediators.base.SequenceMediator.mediate()
call the mediate method in the out-sequence
org.apache.synapse.mediators.AbstractListMediator.mediate()
iterates through mediators in the out-sequence
org.apache.synapse.mediators.builtin.SendMediator.mediate()
org.apache.synapse.core.axis2.Axis2Sender.sendBack
This blog post describes the message flow of ESB at the synapse level from the client to backend and then backend to client.
To trace the message flow we can deploy a proxy service and invoke that,
<?xml version="1.0" encoding="UTF-8"?>
<proxy xmlns="http://ws.apache.org/ns/synapse"
name="TestProxy"
startOnLoad="true"
statistics="disable"
trace="disable"
transports="https,http">
<target>
<inSequence>
<log/>
<send>
<endpoint>
<address uri="http://www.mocky.io/v2/5924085b100000771e003629"/>
</endpoint>
</send>
</inSequence>
</target>
<description/>
</proxy>
When a request comes from the client side, at the synapse level, it first hits the receive method in ProxyServiceMessageReceiver. This is the message flow in the request flow,
In-Flow
org.apache.synapse.core.axis2.ProxyServiceMessageReceiver.receive
at this level having the axis2 message context
org.apache.synapse.core.axis2.MessageContextCreatorForAxis2.getSynapseMessageContext
get the synapse message context out of it
org.apache.synapse.core.axis2.ProxyService.registerFaultHandler
fault handler is registered for the proxy service
org.apache.synapse.mediators.base.SequenceMediator.mediate
call the mediate method in the in-sequence
org.apache.synapse.mediator.AbstractListMediator.mediate
iterates through mediators in the in-sequence
org.apache.synapse.mediators.builtin.SendMediator.mediate
org.apache.synapse.endpoints.AddressEndpoint.send
org.apache.synapse.core.axis2.Axis2Sender.sendOn
org.apache.synapse.core.axis2.Axis2FlexibleMEPClient.send
Out-Flow
org.apache.synapse.core.axis2.SynapseCallbackReceiver.receive
org.apache.synapse.core.axis2.SynapseCallbackReceiver.handleMessage
org.apache.synapse.core.axis2.Axis2SynapseEnvironment.injectMessage
org.apache.synapse.mediators.base.SequenceMediator.mediate()
call the mediate method in the out-sequence
org.apache.synapse.mediators.AbstractListMediator.mediate()
iterates through mediators in the out-sequence
org.apache.synapse.mediators.builtin.SendMediator.mediate()
org.apache.synapse.core.axis2.Axis2Sender.sendBack
Thursday, August 4, 2016
Guaranteed delivery of emails using WSO2 ESB and WSO2 MB
WSO2 ESB provides guaranteed message delivery through it's message store and message processor. Here, I'm going to talk about a usecase where how to send an email through its recipient even the mail server is unavailable at the time the email is sent. Let's start with the setup.
1. Download a distribution of the WSO2 ESB from here. Extract the zip file. The folder created will be referred as ESB_HOME. Download the message broker. WSO2 MB is used as the message broker in this document, therefore, download the WSO2 MB from the official site, extract the zip file. This folder will be referred as MB_HOME.
1. Download a distribution of the WSO2 ESB from here. Extract the zip file. The folder created will be referred as ESB_HOME. Download the message broker. WSO2 MB is used as the message broker in this document, therefore, download the WSO2 MB from the official site, extract the zip file. This folder will be referred as MB_HOME.
2. As we are going to mailto transport to send mails, uncomment the mailto TransportSender and TransportReceiver from axis2.xml in the ESB server
ie. ESB_HOME/conf/axis2.xml
<transportSender name="mailto" class="org.apache.axis2.transport.mail.MailTransportSender">
<parameter name="mail.smtp.host">smtp.gmail.com</parameter>
<parameter name="mail.smtp.port">587</parameter>
<parameter name="mail.smtp.starttls.enable">true</parameter>
<parameter name="mail.smtp.auth">true</parameter>
<parameter name="mail.smtp.user">email.user</parameter>
<parameter name="mail.smtp.password">email.user.password</parameter>
<parameter name="mail.smtp.from">email.user@gmail.com</parameter>
</transportSender>
<transportReceiver name="mailto" class="org.apache.axis2.transport.mail.MailTransportListener">
</transportReceiver>
</transportReceiver>
You have to give the senders credentials and the mail servers details under transportSender section
3. Copy the following JAR files from the <MB_HOME>/clent-lib directory to the <ESB_HOME>/repository/components/lib directory
- andes-client-3.0.1.jar
- geronimo-jms_1.1_spec-1.1.0.wso2v1.jar
4. Open <ESB_HOME>/repository/conf/jndi.properties file and make a reference to the running Message Broker as specified below:
- Use carbon as the virtual host.
- Define a queue named JMSMS
- Comment out the topic, since it is not required in this scenario. However, in order to avoid getting the javax.naming.NameNotFoundException:TopicConnectionFactory exception during server startup, make a reference to the Message Broker from the TopicConnectionFactory as well.
5. Now the ESB server is configured. Then we have to configure MB server. Uncomment the jms transport receiver and sender for WSO2 MB in axis2.xml
<transportReceiver name="jms" class="org.apache.axis2.transport.jms.JMSListener">
<parameter name="myTopicConnectionFactory" locked="false">
<parameter name="java.naming.factory.initial" locked="false">org.wso2.andes.jndi.PropertiesFileInitialContextFactory</parameter>
<parameter name="java.naming.provider.url" locked="false">repository/conf/jndi.properties</parameter>
<parameter name="transport.jms.ConnectionFactoryJNDIName" locked="false">TopicConnectionFactory</parameter>
<parameter name="transport.jms.ConnectionFactoryType" locked="false">topic</parameter>
</parameter>
<parameter name="myQueueConnectionFactory" locked="false">
<parameter name="java.naming.factory.initial" locked="false">org.wso2.andes.jndi.PropertiesFileInitialContextFactory</parameter>
<parameter name="java.naming.provider.url" locked="false">repository/conf/jndi.properties</parameter>
<parameter name="transport.jms.ConnectionFactoryJNDIName" locked="false">QueueConnectionFactory</parameter>
<parameter name="transport.jms.ConnectionFactoryType" locked="false">queue</parameter>
</parameter>
<parameter name="default" locked="false">
<parameter name="java.naming.factory.initial" locked="false">org.wso2.andes.jndi.PropertiesFileInitialContextFactory</parameter>
<parameter name="java.naming.provider.url" locked="false">repository/conf/jndi.properties</parameter>
<parameter name="transport.jms.ConnectionFactoryJNDIName" locked="false">QueueConnectionFactory</parameter>
<parameter name="transport.jms.ConnectionFactoryType" locked="false">queue</parameter>
</parameter>
</transportReceiver>
<transportSender name="jms" class="org.apache.axis2.transport.jms.JMSSender"/>
6. As we are running two carbon servers on the same machine, apply a port offset in the <MB_HOME>/repository/conf/carbon.xml file by changing the offset value to 1. For example,
<Ports>
<!-- Ports offset. This entry will set the value of the ports defined below to
the define value + Offset.
e.g. Offset=2 and HTTPS port=9443 will set the effective HTTPS port to 9445
-->
<Offset>1</Offset>
7. Start the ESB server and MB server
8. On ESB server Create the failover message store
In this example usecase an in-memory message store is used to create the failover message store.
<messageStore name="Failover"/>
9. Create the original message store as illustrated in the diagram. I have used JMS message store for this purpose. When creating the original message store, you need to enable guaranteed delivery on the producer side. A sample config would be as below,
<messageStore name="Original" class="org.apache.synapse.message.store.impl.jms.JmsStore" xmlns="http://ws.apache.org/ns/synapse">
<parameter name="java.naming.factory.initial">org.wso2.andes.jndi.PropertiesFileInitialContextFactory</parameter>
<parameter name="java.naming.provider.url">repository/conf/jndi.properties</parameter>
<parameter name="store.jms.JMSSpecVersion">1.1</parameter>
<parameter name="store.producer.guaranteed.delivery.enable">true</parameter>
<parameter name="store.failover.message.store.name">Failover</parameter>
</messageStore>
10. Create a proxy service to send the email to designation. This proxy is treated as the backend service which calls the mail server and delivers the emails.
<proxy xmlns="http://ws.apache.org/ns/synapse"
name="MailToProxy"
transports="https,http"
statistics="disable"
trace="disable"
startOnLoad="true">
<target>
<inSequence>
<property name="senderAddress" value="chanika1118@gmail.com"/>
<log level="full">
<property name="Sender Address" expression="get-property('senderAddress')"/>
</log>
<property name="FORCE_SC_ACCEPTED" value="true" scope="axis2"/>
<property name="OUT_ONLY" value="true"/>
<property name="Subject" value="This is a test" scope="transport"/>
<property name="messageType" value="text/plain" scope="axis2-client"/>
<script language="js">mc.setPayloadXML(<ns:text xmlns:ns="http://ws.apache.org/commons/ns/payload">Plain text received!</ns:text>);</script>
<header name="To"
expression="fn:concat('mailto:', get-property('senderAddress'))"/>
<log level="full">
<property name="message" value="Response message"/>
<property name="Sender Address" expression="get-property('senderAddress')"/>
</log>
<send/>
</inSequence>
<outSequence>
<send/>
</outSequence>
<faultSequence>
<property name="FORCE_SC_ACCEPTED" value="true" scope="axis2"/>
<property name="OUT_ONLY" value="true"/>
<log level="full"/>
<store messageStore="Failover"/>
</faultSequence>
</target>
<description/>
</proxy>
As you can see, if there is an error occurred when sending the email, it goes to the fault sequence and within the fault sequence it calls the ‘Failover’ message store in order to make sure that the message will be delivered when the connectivity is back.
11. Add Endpoint to call the proxy service
<endpoint xmlns="http://ws.apache.org/ns/synapse" name="MailDeliveryService">
<address uri="http://localhost:8280/services/MailToProxy">
<suspendOnFailure>
<progressionFactor>1.0</progressionFactor>
</suspendOnFailure>
<markForSuspension>
<retriesBeforeSuspension>0</retriesBeforeSuspension>
<retryDelay>0</retryDelay>
</markForSuspension>
</address>
</endpoint>
12. Add a proxy service to invoke the mail delivery endpoint.
<proxy xmlns="http://ws.apache.org/ns/synapse"
name="SampleProxy"
transports="https,http"
statistics="disable"
trace="disable"
startOnLoad="true">
<target>
<inSequence>
<send>
<endpoint key="MailDeliveryService"/>
</send>
</inSequence>
</target>
<description/>
</proxy>
13. Add Scheduled Message Forwarding Processor to forward the request to the defined endpoint.
<messageProcessor name="ForwardMessageProcessor" class="org.apache.synapse.message.processor.impl.forwarder.ScheduledMessageForwardingProcessor" targetEndpoint="MailDeliveryService" messageStore="Original" xmlns="http://ws.apache.org/ns/synapse">
<parameter name="interval">1000</parameter>
<parameter name="client.retry.interval">1000</parameter>
<parameter name="max.delivery.attempts">4</parameter>
<parameter name="is.active">true</parameter>
<parameter name="max.delivery.drop">Disabled</parameter>
<parameter name="member.count">1</parameter>
</messageProcessor>
14. Add Scheduled Failover Message Forwarding Processor to send messages from the failover store to the original store when it is available in the failover scenario. In there you have to define the source message store (which is failover store in our scenario) and the target message store (which is original message store in our scenario)
<messageProcessor name="FailoverMessageProcessor" class="org.apache.synapse.message.processor.impl.failover.FailoverScheduledMessageForwardingProcessor" messageStore="Failover" xmlns="http://ws.apache.org/ns/synapse">
<parameter name="interval">1000</parameter>
<parameter name="client.retry.interval">60000</parameter>
<parameter name="max.delivery.attempts">1000</parameter>
<parameter name="is.active">true</parameter>
<parameter name="max.delivery.drop">Disabled</parameter>
<parameter name="member.count">1</parameter>
<parameter name="message.target.store.name">Orginal</parameter>
</messageProcessor>
Now everything is setup. It is time to test the scenario. You can invoke the SampleProxy and see how the mails are received to the recipient defined in the proxy service.
The failover scenario can be tested by dropping the connection between the ESB server and the mail server or shutdown the mail server. Then you can send some messages to the ESB SampleProxy service. If you check the logs you will see that the failover message processor periodically sends messages to the original message store and eventually tries to send messages to the mail server continuously through the scheduled message forwarding processor. Moreover, the emails are not sent to the receiver address since there is a connectivity issue. The message count of the failover message store is changing over time with the number of messages sent to the proxy service and the number of messages pulled out from the failover message store in order to send to the original message store.
Once you enable connectivity between the ESB server and the mail server, the messages pulled out from the failover message store are sent to the recipients.
<transportReceiver name="jms" class="org.apache.axis2.transport.jms.JMSListener">
<parameter name="myTopicConnectionFactory" locked="false">
<parameter name="java.naming.factory.initial" locked="false">org.wso2.andes.jndi.PropertiesFileInitialContextFactory</parameter>
<parameter name="java.naming.provider.url" locked="false">repository/conf/jndi.properties</parameter>
<parameter name="transport.jms.ConnectionFactoryJNDIName" locked="false">TopicConnectionFactory</parameter>
<parameter name="transport.jms.ConnectionFactoryType" locked="false">topic</parameter>
</parameter>
<parameter name="myQueueConnectionFactory" locked="false">
<parameter name="java.naming.factory.initial" locked="false">org.wso2.andes.jndi.PropertiesFileInitialContextFactory</parameter>
<parameter name="java.naming.provider.url" locked="false">repository/conf/jndi.properties</parameter>
<parameter name="transport.jms.ConnectionFactoryJNDIName" locked="false">QueueConnectionFactory</parameter>
<parameter name="transport.jms.ConnectionFactoryType" locked="false">queue</parameter>
</parameter>
<parameter name="default" locked="false">
<parameter name="java.naming.factory.initial" locked="false">org.wso2.andes.jndi.PropertiesFileInitialContextFactory</parameter>
<parameter name="java.naming.provider.url" locked="false">repository/conf/jndi.properties</parameter>
<parameter name="transport.jms.ConnectionFactoryJNDIName" locked="false">QueueConnectionFactory</parameter>
<parameter name="transport.jms.ConnectionFactoryType" locked="false">queue</parameter>
</parameter>
</transportReceiver>
<transportSender name="jms" class="org.apache.axis2.transport.jms.JMSSender"/>
6. As we are running two carbon servers on the same machine, apply a port offset in the <MB_HOME>/repository/conf/carbon.xml file by changing the offset value to 1. For example,
<Ports>
<!-- Ports offset. This entry will set the value of the ports defined below to
the define value + Offset.
e.g. Offset=2 and HTTPS port=9443 will set the effective HTTPS port to 9445
-->
<Offset>1</Offset>
7. Start the ESB server and MB server
8. On ESB server Create the failover message store
In this example usecase an in-memory message store is used to create the failover message store.
<messageStore name="Failover"/>
9. Create the original message store as illustrated in the diagram. I have used JMS message store for this purpose. When creating the original message store, you need to enable guaranteed delivery on the producer side. A sample config would be as below,
<messageStore name="Original" class="org.apache.synapse.message.store.impl.jms.JmsStore" xmlns="http://ws.apache.org/ns/synapse">
<parameter name="java.naming.factory.initial">org.wso2.andes.jndi.PropertiesFileInitialContextFactory</parameter>
<parameter name="java.naming.provider.url">repository/conf/jndi.properties</parameter>
<parameter name="store.jms.JMSSpecVersion">1.1</parameter>
<parameter name="store.producer.guaranteed.delivery.enable">true</parameter>
<parameter name="store.failover.message.store.name">Failover</parameter>
</messageStore>
10. Create a proxy service to send the email to designation. This proxy is treated as the backend service which calls the mail server and delivers the emails.
<proxy xmlns="http://ws.apache.org/ns/synapse"
name="MailToProxy"
transports="https,http"
statistics="disable"
trace="disable"
startOnLoad="true">
<target>
<inSequence>
<property name="senderAddress" value="chanika1118@gmail.com"/>
<log level="full">
<property name="Sender Address" expression="get-property('senderAddress')"/>
</log>
<property name="FORCE_SC_ACCEPTED" value="true" scope="axis2"/>
<property name="OUT_ONLY" value="true"/>
<property name="Subject" value="This is a test" scope="transport"/>
<property name="messageType" value="text/plain" scope="axis2-client"/>
<script language="js">mc.setPayloadXML(<ns:text xmlns:ns="http://ws.apache.org/commons/ns/payload">Plain text received!</ns:text>);</script>
<header name="To"
expression="fn:concat('mailto:', get-property('senderAddress'))"/>
<log level="full">
<property name="message" value="Response message"/>
<property name="Sender Address" expression="get-property('senderAddress')"/>
</log>
<send/>
</inSequence>
<outSequence>
<send/>
</outSequence>
<faultSequence>
<property name="FORCE_SC_ACCEPTED" value="true" scope="axis2"/>
<property name="OUT_ONLY" value="true"/>
<log level="full"/>
<store messageStore="Failover"/>
</faultSequence>
</target>
<description/>
</proxy>
As you can see, if there is an error occurred when sending the email, it goes to the fault sequence and within the fault sequence it calls the ‘Failover’ message store in order to make sure that the message will be delivered when the connectivity is back.
11. Add Endpoint to call the proxy service
<endpoint xmlns="http://ws.apache.org/ns/synapse" name="MailDeliveryService">
<address uri="http://localhost:8280/services/MailToProxy">
<suspendOnFailure>
<progressionFactor>1.0</progressionFactor>
</suspendOnFailure>
<markForSuspension>
<retriesBeforeSuspension>0</retriesBeforeSuspension>
<retryDelay>0</retryDelay>
</markForSuspension>
</address>
</endpoint>
12. Add a proxy service to invoke the mail delivery endpoint.
<proxy xmlns="http://ws.apache.org/ns/synapse"
name="SampleProxy"
transports="https,http"
statistics="disable"
trace="disable"
startOnLoad="true">
<target>
<inSequence>
<send>
<endpoint key="MailDeliveryService"/>
</send>
</inSequence>
</target>
<description/>
</proxy>
13. Add Scheduled Message Forwarding Processor to forward the request to the defined endpoint.
<messageProcessor name="ForwardMessageProcessor" class="org.apache.synapse.message.processor.impl.forwarder.ScheduledMessageForwardingProcessor" targetEndpoint="MailDeliveryService" messageStore="Original" xmlns="http://ws.apache.org/ns/synapse">
<parameter name="interval">1000</parameter>
<parameter name="client.retry.interval">1000</parameter>
<parameter name="max.delivery.attempts">4</parameter>
<parameter name="is.active">true</parameter>
<parameter name="max.delivery.drop">Disabled</parameter>
<parameter name="member.count">1</parameter>
</messageProcessor>
14. Add Scheduled Failover Message Forwarding Processor to send messages from the failover store to the original store when it is available in the failover scenario. In there you have to define the source message store (which is failover store in our scenario) and the target message store (which is original message store in our scenario)
<messageProcessor name="FailoverMessageProcessor" class="org.apache.synapse.message.processor.impl.failover.FailoverScheduledMessageForwardingProcessor" messageStore="Failover" xmlns="http://ws.apache.org/ns/synapse">
<parameter name="interval">1000</parameter>
<parameter name="client.retry.interval">60000</parameter>
<parameter name="max.delivery.attempts">1000</parameter>
<parameter name="is.active">true</parameter>
<parameter name="max.delivery.drop">Disabled</parameter>
<parameter name="member.count">1</parameter>
<parameter name="message.target.store.name">Orginal</parameter>
</messageProcessor>
Now everything is setup. It is time to test the scenario. You can invoke the SampleProxy and see how the mails are received to the recipient defined in the proxy service.
The failover scenario can be tested by dropping the connection between the ESB server and the mail server or shutdown the mail server. Then you can send some messages to the ESB SampleProxy service. If you check the logs you will see that the failover message processor periodically sends messages to the original message store and eventually tries to send messages to the mail server continuously through the scheduled message forwarding processor. Moreover, the emails are not sent to the receiver address since there is a connectivity issue. The message count of the failover message store is changing over time with the number of messages sent to the proxy service and the number of messages pulled out from the failover message store in order to send to the original message store.
Once you enable connectivity between the ESB server and the mail server, the messages pulled out from the failover message store are sent to the recipients.
Tuesday, July 21, 2015
Resolve - keytool error: java.lang.Exception: Failed to establish chain from reply
This blog post is related to my previous post 'Add CA signed certificate to keystore'. When you are going to import the CA signed certificate to your keystore, you may be getting the following error
keytool error: java.lang.Exception: Failed to establish chain from reply
The cause of this error
keytool error: java.lang.Exception: Failed to establish chain from reply
The cause of this error
This error occurs if
- the correct root certificate is not imported to the keystore
- the correct intermediate certificate is not imported to the keystore
The root cause is when you are going to import the signed certificate it checks whether it can create a chain from issuer and subject parameters in the imported certificate.
The solution is to
Import the correct root and intermediate which is compatible with the CA and the certificate type. For and example if you are using VeriSign you can find all the intermediate and root certificates from here.
Add CA signed certificate to keystore
A keystore is a file that keeps private keys, certificates and symmetric keys as key value pair. Each certificate is uniquely identified by an identifier called as 'Alias'. In this blog post I will go through a very common usecase where we have to get a certificate signed by CA and import that to the keystore.
As a prerequisite we have to make sure that Java is installed correctly and the class path is set. Then we can follow the following steps
1. Create a key store
You can create your own keystore by executing the following command.
keytool -genkey -alias democert -keyalg RSA -keystore demokeystore.jks -keysize 2048
You will be prompted to give below required information and a password for the keystore.
Enter keystore password:
Re-enter new password:
What is your first and last name?
[Unknown]: localhost
What is the name of your organizational unit?
[Unknown]: wso2
What is the name of your organization?
[Unknown]: wso2
What is the name of your City or Locality?
[Unknown]: colombo
What is the name of your State or Province?
[Unknown]: WP
What is the two-letter country code for this unit?
[Unknown]: LK
Is CN=localhost, OU=wso2, O=wso2, L=colombo, ST=WP, C=LK correct?
[no]: yes
Enter key password for <democert>
(RETURN if same as keystore password):
This generates a private key and the certificate with the alias specified in the command (ex: democert).
Once you executed the above command a new file with the name demokeystore.jks will be created at your the location you executed the command.
2. View the content in the created keystore.
You can execute the following command in order to view the content of the created keystore in step 1.
keytool -list -v -keystore demokeystore.jks -storepass password
You will receive an output similar to
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 1 entry
Alias name: democert
Creation date: Jul 21, 2015
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=localhost, OU=wso2, O=wso2, L=colombo, ST=WP, C=LK
Issuer: CN=localhost, OU=wso2, O=wso2, L=colombo, ST=WP, C=LK
Serial number: 2ef9b438
Valid from: Tue Jul 21 18:46:12 IST 2015 until: Mon Oct 19 18:46:12 IST 2015
Certificate fingerprints:
MD5: 2F:1B:EF:8E:95:5D:0E:0F:81:34:FE:4A:27:A9:68:A8
SHA1: FD:9D:98:A1:FB:36:DD:6B:D7:1A:F6:E8:AC:98:35:3A:5E:3C:7F:9A
SHA256: CF:02:15:41:9E:CC:67:65:85:33:4A:E4:3D:B9:C4:C5:B2:04:CD:A8:FF:B6:63:D6:DB:DC:79:85:51:79:FA:1E
Signature algorithm name: SHA256withRSA
Version: 3
Extensions:
#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 9B D4 69 A2 D9 A8 E0 22 02 D6 4F 57 71 3B 27 F4 ..i...."..OWq;'.
0010: 18 8E 7F 4F ...O
]
]
*******************************************
*******************************************
3. Create CSR
The certificate in the create keystore is a self-signed certificate. But you need to get your certificate signed by a Certificate Authority(CA). For that a Certificate Signing Request (CSR) has to be generated. You can use the following command for that.
keytool -certreq -v -alias democert -file csr_request.pem -keypass password -storepass password -keystore demokeystore.jks
Then a csr_request.pem file is created in the location that you have executed this command.
4. Get the certificate signed by CA
In this blog post I'm going to use VeriSign free trail version to get the certificate signed. If you are using this trial version the certificate is valid for only 30 day. Follow the wizard in here. When you are asked to give the CSR, open the generated csr_request.pem in a text editor and copy the content and paste in the text area in the wizard. After you have completed the wizard you will be received an email from VeriSign with the signed certificate.
5. Import the root and intermediate certificates to the keystore
Before importing the signed certificate you have to import the root and intermediate certificates to the keystore. The root certificate for VeriSign trial version can be found from here. Copy the text in the root certificate to a new file and save it as verisign_root.pem file
Now you can import the root certificate to the keystore by executing the following command.
keytool -import -v -noprompt -trustcacerts -alias verisigndemoroot -file verisign_root.pem -keystore demokeystore.jks -storepass password
Now the root cert is imported. You can verify that by listing the content in the keystore. (step2)
The next step is to import the intermediate cert file. For the VeriSign trial version you can get the intermediate certificate from here. Copy the text and save that in a new file (verisign_intermediate.pem)
Import the intermediate certificate:
keytool -import -v -noprompt -trustcacerts -alias verisigndemoim -file verisign_intermediate.pem -keystore demokeystore.jks -storepass password
6. Import the CA signed certificate to keystore
Now we can import the signed certificate. You can find the certificate in the email you received from VeriSign. Copy the text file. For and example,
-----BEGIN CERTIFICATE-----
MIIEtTCCA52gAwIBAgIQG+
jTELMAkGA1UEBhMCVVMxHTAbBgNVBA
LgYDVQQLEydGb3IgVGVzdCBQdXJwb3
LTArBgNVBAMTJFN5bWFudGVjIFRyaW
Fw0xNTA3MjAwMDAwMDBaFw0xNTA4MT
CQYDVQQIEwJXUDEMMAoGA1UEBxQDQ0
FAR3c28yMRIwEAYDVQQDFAlsb2NhbG
DwAwggEKAoIBAQC8YacCtuAHjcUheG
LpCd1qfeDkqGVBnoizcCvuqmMy9a6j
igpvOnEAcoDJdmjSMQawSVIy5XO9aL
Vjp/cQQenljSgmw+
STb47324GmlT6PF5T0e0+
dVHqDa3E8YNJNPyqwApOUw5yFUxokA
DTALgglsb2NhbGhvc3QwCQYDVR0TBA
BCQwIjAgoB6gHIYaaHR0cDovL3JlLn
XDBaBgpghkgBhvhFAQcVMEwwIwYIKw
b20vY3BzMCUGCCsGAQUFBwICMBkMF2
A1UdJQQWMBQGCCsGAQUFBwMBBggrBg
iUDnFiFocUQ1XSrQvjA2BggrBgEFBQ
Ly9yZS5zeW1jYi5jb20vcmUuY3J0MA
ok8HP0QJTwRh2J5dwawQKPB9dauqcG
jhdMk51fRkaGtli6N84V5Db7bRYARn
rBtVv47PXIykgXEaGzECrIT/
sGp7lmGWjy01j1mYTfHzVWOKQmiheW
eSy7pIOcy4nvHh7h07UsjivGNIIfQ6
LZtGg2ZrFIsd
-----END CERTIFICATE-----
Create a new text file and past this content and save it as verisign_signed.pem
Import that with the following command
keytool -import -v -alias democert -file verisign_signed.pem -keystore demokeystore.jks -keypass password -storepass password
Now you have the CA signed certificate in your keystore. You can verify that by listing the certificate in the keystore as you did in the step2
As a prerequisite we have to make sure that Java is installed correctly and the class path is set. Then we can follow the following steps
1. Create a key store
You can create your own keystore by executing the following command.
keytool -genkey -alias democert -keyalg RSA -keystore demokeystore.jks -keysize 2048
You will be prompted to give below required information and a password for the keystore.
Enter keystore password:
Re-enter new password:
What is your first and last name?
[Unknown]: localhost
What is the name of your organizational unit?
[Unknown]: wso2
What is the name of your organization?
[Unknown]: wso2
What is the name of your City or Locality?
[Unknown]: colombo
What is the name of your State or Province?
[Unknown]: WP
What is the two-letter country code for this unit?
[Unknown]: LK
Is CN=localhost, OU=wso2, O=wso2, L=colombo, ST=WP, C=LK correct?
[no]: yes
Enter key password for <democert>
(RETURN if same as keystore password):
This generates a private key and the certificate with the alias specified in the command (ex: democert).
Once you executed the above command a new file with the name demokeystore.jks will be created at your the location you executed the command.
2. View the content in the created keystore.
You can execute the following command in order to view the content of the created keystore in step 1.
keytool -list -v -keystore demokeystore.jks -storepass password
You will receive an output similar to
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 1 entry
Alias name: democert
Creation date: Jul 21, 2015
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=localhost, OU=wso2, O=wso2, L=colombo, ST=WP, C=LK
Issuer: CN=localhost, OU=wso2, O=wso2, L=colombo, ST=WP, C=LK
Serial number: 2ef9b438
Valid from: Tue Jul 21 18:46:12 IST 2015 until: Mon Oct 19 18:46:12 IST 2015
Certificate fingerprints:
MD5: 2F:1B:EF:8E:95:5D:0E:0F:81:34:FE:4A:27:A9:68:A8
SHA1: FD:9D:98:A1:FB:36:DD:6B:D7:1A:F6:E8:AC:98:35:3A:5E:3C:7F:9A
SHA256: CF:02:15:41:9E:CC:67:65:85:33:4A:E4:3D:B9:C4:C5:B2:04:CD:A8:FF:B6:63:D6:DB:DC:79:85:51:79:FA:1E
Signature algorithm name: SHA256withRSA
Version: 3
Extensions:
#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 9B D4 69 A2 D9 A8 E0 22 02 D6 4F 57 71 3B 27 F4 ..i...."..OWq;'.
0010: 18 8E 7F 4F ...O
]
]
*******************************************
*******************************************
3. Create CSR
The certificate in the create keystore is a self-signed certificate. But you need to get your certificate signed by a Certificate Authority(CA). For that a Certificate Signing Request (CSR) has to be generated. You can use the following command for that.
keytool -certreq -v -alias democert -file csr_request.pem -keypass password -storepass password -keystore demokeystore.jks
Then a csr_request.pem file is created in the location that you have executed this command.
4. Get the certificate signed by CA
In this blog post I'm going to use VeriSign free trail version to get the certificate signed. If you are using this trial version the certificate is valid for only 30 day. Follow the wizard in here. When you are asked to give the CSR, open the generated csr_request.pem in a text editor and copy the content and paste in the text area in the wizard. After you have completed the wizard you will be received an email from VeriSign with the signed certificate.
5. Import the root and intermediate certificates to the keystore
Before importing the signed certificate you have to import the root and intermediate certificates to the keystore. The root certificate for VeriSign trial version can be found from here. Copy the text in the root certificate to a new file and save it as verisign_root.pem file
Now you can import the root certificate to the keystore by executing the following command.
keytool -import -v -noprompt -trustcacerts -alias verisigndemoroot -file verisign_root.pem -keystore demokeystore.jks -storepass password
Now the root cert is imported. You can verify that by listing the content in the keystore. (step2)
The next step is to import the intermediate cert file. For the VeriSign trial version you can get the intermediate certificate from here. Copy the text and save that in a new file (verisign_intermediate.pem)
Import the intermediate certificate:
keytool -import -v -noprompt -trustcacerts -alias verisigndemoim -file verisign_intermediate.pem -keystore demokeystore.jks -storepass password
6. Import the CA signed certificate to keystore
Now we can import the signed certificate. You can find the certificate in the email you received from VeriSign. Copy the text file. For and example,
-----BEGIN CERTIFICATE-----
MIIEtTCCA52gAwIBAgIQG+
jTELMAkGA1UEBhMCVVMxHTAbBgNVBA
LgYDVQQLEydGb3IgVGVzdCBQdXJwb3
LTArBgNVBAMTJFN5bWFudGVjIFRyaW
Fw0xNTA3MjAwMDAwMDBaFw0xNTA4MT
CQYDVQQIEwJXUDEMMAoGA1UEBxQDQ0
FAR3c28yMRIwEAYDVQQDFAlsb2NhbG
DwAwggEKAoIBAQC8YacCtuAHjcUheG
LpCd1qfeDkqGVBnoizcCvuqmMy9a6j
igpvOnEAcoDJdmjSMQawSVIy5XO9aL
Vjp/cQQenljSgmw+
STb47324GmlT6PF5T0e0+
dVHqDa3E8YNJNPyqwApOUw5yFUxokA
DTALgglsb2NhbGhvc3QwCQYDVR0TBA
BCQwIjAgoB6gHIYaaHR0cDovL3JlLn
XDBaBgpghkgBhvhFAQcVMEwwIwYIKw
b20vY3BzMCUGCCsGAQUFBwICMBkMF2
A1UdJQQWMBQGCCsGAQUFBwMBBggrBg
iUDnFiFocUQ1XSrQvjA2BggrBgEFBQ
Ly9yZS5zeW1jYi5jb20vcmUuY3J0MA
ok8HP0QJTwRh2J5dwawQKPB9dauqcG
jhdMk51fRkaGtli6N84V5Db7bRYARn
rBtVv47PXIykgXEaGzECrIT/
sGp7lmGWjy01j1mYTfHzVWOKQmiheW
eSy7pIOcy4nvHh7h07UsjivGNIIfQ6
LZtGg2ZrFIsd
-----END CERTIFICATE-----
Create a new text file and past this content and save it as verisign_signed.pem
Import that with the following command
keytool -import -v -alias democert -file verisign_signed.pem -keystore demokeystore.jks -keypass password -storepass password
Now you have the CA signed certificate in your keystore. You can verify that by listing the certificate in the keystore as you did in the step2
Wednesday, December 3, 2014
Invoking ws-secured (username token) service from WSO2 API Manager
In this blog post I'm going to talk about a usecase scenario where I want to invoke a ws-secured web service (username token) via WSO2 API Manager. For the demonstration purposes I use WSO2 DSS to create a ws-secured web service. Here are the steps
1. Download WSO2 APIManager (at the moment 1.7.0) and WSO2 DSS (at the moment 3.2.2)
2. Extract two products zip files. As both products run in the same machine, change the port offset in either of the instance. Here I'm going to do that change in DSS instance. For that edit the carbon.xml (in $SERVER_ROOT/repository/conf) and change the following in the DSS.
<Offset>0</Offset>
to
<Offset>1</Offset>
3. Run the ant script in the DSS samples
4. Start both servers
5. In the DSS server the sample dataservices should be now deployed. Secure the "samples/ResourcesSample" dataservice with username token ws-security policy.
6. Try to invoke the following REST URL with username and password as 'admin'
https://localhost:9444/services/samples/ResourcesSample/products
7. Create an API from API Manager. Go to API publisher and add an API
8. Give the ws-secured service as the endpoint
9. Click on 'Show More Options' link and select 'Secured' from drop down and give admin as credentials.
10. Publish the API. In the API store subscribe to the API and invoke the API with the necessary authorization access token. You will be able to see the result.
1. Download WSO2 APIManager (at the moment 1.7.0) and WSO2 DSS (at the moment 3.2.2)
2. Extract two products zip files. As both products run in the same machine, change the port offset in either of the instance. Here I'm going to do that change in DSS instance. For that edit the carbon.xml (in $SERVER_ROOT/repository/conf) and change the following in the DSS.
<Offset>0</Offset>
to
<Offset>1</Offset>
3. Run the ant script in the DSS samples
4. Start both servers
5. In the DSS server the sample dataservices should be now deployed. Secure the "samples/ResourcesSample" dataservice with username token ws-security policy.
6. Try to invoke the following REST URL with username and password as 'admin'
https://localhost:9444/services/samples/ResourcesSample/products
7. Create an API from API Manager. Go to API publisher and add an API
8. Give the ws-secured service as the endpoint
9. Click on 'Show More Options' link and select 'Secured' from drop down and give admin as credentials.
10. Publish the API. In the API store subscribe to the API and invoke the API with the necessary authorization access token. You will be able to see the result.
Subscribe to:
Posts (Atom)