Showing posts with label API. Show all posts
Showing posts with label API. Show all posts

Thursday, February 6, 2014

Mediators : How to use Enrich Mediator to download an image from a URL and use Synapse functions to base64 encode same using WSO2 ESB

We can do this by doing a "GET" on the image URL, this will make the ESB download the contents, after which you may use the Enrich mediator to assign the "body" contents, to a synapse variable.



 
  
 


 
 


 


That should do it. We are not done however, when you run this config you will notice a huge error on the ESB console, like below.

ERROR - DeferredMessageBuilder Error building message using POX Builder
javax.xml.stream.XMLStreamException: com.sun.org.apache.xerces.internal.impl.io.MalformedByteSequenceException: Invalid byte 1 of 1-byte UTF-8 sequence.

This is because ESB is trying to build the image as a XML, since we have not assigned a specific builder to tackle with the its type, which is : image/jpg. We can make this config change in the axis2.xml. (Please refer [1] for further details on this)

<messageBuilder contentType="image/jpeg" class="org.wso2.carbon.relay.BinaryRelayBuilder"/>

<messageFormatter contentType="image/jpeg" class="org.wso2.carbon.relay.ExpandingMessageFormatter"/>

You need to add the formatter under the <messageFormatters> section and builder under the <messageBuilders>.

Ok. We are good to go. Now all that remains to be done is the base64 encoding part. We can simply do this by calling the synapse function base64Encode

The following is an example on how it can be done.

<property name="encoded_image" expression="base64Encode($ctx:image_val)" scope="default" type="STRING" description="base64 encode Image"/>

Thats it.


References :

[1] - http://wso2.com/library/articles/binary-relay-efficient-way-pass-both-xml-non-xml-content-through-apache-synapse/

Wednesday, February 5, 2014

Mediators : How to use WSO2 Script Mediator to do date validations.

The WSO2 ESB provides a whole suite of mediators with which you can do all sorts of request/response/variable manipulations and validations.

This article will be the first of a series of posts to follow on various mediators.

For the sake of this article, we will be using javascript inside the script mediator to do a simple XML DATE validation.



The above code would convert a XML DATE which is of the following format "YYYY-MM-DDTHH:MM:SS" (E.g. : 2010-08-01T00:00:00) to a regular Javascript date, add 5 years to the same and see if current date is greater than said value. Accordingly it would assign a variable to synapse messagecontext, which you may access later as you would any synapse property. (Please refer [1] for additional methods, you may call on the Synapse MessageContext from the script mediator.)

You may use a filter/switch mediator later on in your flow to execute appropriate logic based on the "result" variable you assigned from inside the script.

The script also has logic on how we can do xpath extractions from javascript itself.

var endDay = mc.getPayloadXML()..*::Date.toString(); 

This will seek out an xml elements like <Date>2010-08-01T00:00:00</Date> or JSON elements like
{"Date" : "2010-08-01T00:00:00"}. The principal to remember here is that WSO2 ESB converts JSON requests/responses to XML format in it the run time. So with the above line of code, you may access both XML and JSON payloads, like you would any XPATH.

Note that you may either embed the script inline (like above) or either store it in the registry as a file and point like

<script language="js" key="gov:trunk/scripts/test.js" function="validateDate"/>

References :

Sunday, August 4, 2013

How to configure WSO2 Api Manager with PostgreSQL


Most Enterprise level application developers tend to use PostgreSQL over MySql as their open source Database of choice, due to it's close compliance with SQL standards, compared to the former. What this means is, if at some point the application owner chooses to go ahead with a closed-source solution such as Oracle for its database, the swap can be accomplished with much of a hassle.

This article will discuss the installation of PostgreSQL and configuration of the same with WSO2 Api Manager, on a linux Debian distribution.

Please note that if you have several installations of PostgreSQL locally or have had trouble getting it to work due to corrupt installations and etc. I would suggest starting off with a clean slate. Hence, you may run the commands listed below to completely uninstall PostgreSQL from your system.

apt-get --purge remove postgresql\*

Now lets delete all configurations.

rm -r /etc/postgresql*
rm -r /var/lib/postgresql*
userdel -r postgres
groupdel postgres

So lets start with the installation. Just type the following command.

sudo apt-get install postgresql

Ok, now that you have installed PostgreSQL, lets set it up. At the time of installation PostgreSQL will create a user by the name "postgres". Executing the following command will log you in to the PSQL admin console

sudo -u postgres psql

Enter the admin user password and you should see a prompt indicating "postgres=#".
Now lets go ahead and create two databases. One for the API Manager specific tables, lets call it "am_db". Another for the WSO2 Carbon tables, lets call it "carbon_db". Remember, even if you use upper case to create the databases, the persisted database name will comprise of only lowercase characters, hence might as well go with lower case at the time of creation.

create database am_db;
create database carbon_db;

Now, we need to create the tables. The API Manager pack comes with the scripts to create each set of tables they can be found inside the "dbscripts" folder of the AM zip.

The carbon DB script is at <AM_home>/dbscripts/postgresql.sql
The carbon DB script is at <AM_home>/dbscripts/apimgt/postgresql.sql

Remember what we learned earlier about the user "postgres" you will need be logged in as this user to execute whatever PostgreSQL scripts that you may wish to run.

Before attempting that, lets change the password of the 'postgres' user. I found it easier to do, rather that scour the internet  to find what the default password was. Just login as admin user and change it to a desirable value via the following command.

passwd postgres;

Lets login as 'potgres' via;

su - postgres;
and execute the two table creation scripts against each Database;

psql -d am_db -a -f <path_to_am_script>/postgresql.sql 
psql -d carbon_db -a -f <path_to_carbon_script>/postgresql.sql 

Voila! now you have the two databases setup. What's left is to configure the "master-datasources.xml" inside <AM_HOME>/repository/conf/datasources/, add the PSQL driver and start the server.

You will need to change the WSO2_CARBON_DB and WSO2AM_DB data sources in the master-datasources file as follows.


 WSO2_CARBON_DB
 The datasource used for registry and user manager
 
  jdbc/WSO2CarbonDB
 
 
  
   jdbc:postgresql://localhost:5432/carbon_db
   postgres
   postgres
   org.postgresql.Driver
   50
   60000
   true
   SELECT 1
   30000
  
 



 WSO2AM_DB
 The datasource used for registry and user manager
 
  jdbc/WSO2AM_DB
 
 
  
   jdbc:postgresql://localhost:5432/am_db
   postgres
   postgres
   org.postgresql.Driver
   50
   60000
   true
   SELECT 1
   30000
  
 

Done? great. Download the PostgreSQL driver relevant for your version from here, and copy the .jar file to the the following location inside the AM Pack.

<AM_HOME>/repository/components/lib/

That's it! go and start API Manager by running "./wso2server.sh" from inside of  <AM_HOME>/bin.