Posts

Showing posts with the label WSO2

WSO2 ESB - How to use filter inside iterate mediator

WSO2 ESB's Iterate mediator plays a very powerful role in the Splitter Enterprise Integration Pattern. Splitter Enterprise Integration Pattern is used when messages contain multiple elements that might have to be processed in different ways. The Splitter breaks out the composite message into a series of individual messages, each containing data related to one item.

WSO2 ESB Iterate mediator split the message based on a given expression and process them separately. So think about a use case like you are getting multiple order items and you want to enrich each order item, by calling another endpoint and finally we need to aggregate all the enriched items.

There you can use the Iterate mediator and after that aggregate mediator to aggregate all the enriched items.

Example:


ESB Proxy Service:

<?xml version="1.0" encoding="UTF-8"?><proxyxmlns="http://ws.apache.org/ns/synapse"name="IteService"transports="http,https"statistics=&q…

WSO2 ESB/EI Callout Mediator Error Scenario

When using WSO2 Enterprise Service Bus, you can use Call, Send and Callout mediators to invoke a service. If you are calling multiple service calls within your meditation sequence, you have to use either Call mediator or Callout mediator.

As per the documentation, WSO2 Team is recommending to use Call mediator instead of the Callout mediator, due to much better performance. However, due to some legacy requirements, we might need to stay with Callout mediator for the time being.

In my use case, there are some mediation scenarios with mutual SSL. So if you have noticed an "UnrecoverableKeyException: Password verification failed" exception in the WSO2Carbon log file and terminal when invoking an endpoint(backend service) using callout mediator, I would recommend you to check the Java SSL keyStore Password(values of the javax.net.ssl.keyStorePassword and javax.net.ssl.trustStorePassword environment variables) in  the /bin/wso2server.sh file or relevant location.

TID:[-1234][][20…

WSO2 ESB/EI Send XML content to backend

When sending XML content inside the payload to the backend via WSO2 ESB,  we have to encode it and send it. In my usecase,  I have a Data Service which is accepting XML content as a parameter.

To implement this requirement, we can't directly define CDATA(blocks of text that are not parsed by XML parser) inside the payload factory mediator. So we have two option to do so.

The first option is that Encode XML content using Script mediator and use encoded value inside the payload factory mediator. You can read Hasitha's blog on this topic.

The second option is storing the format section of the payload factory mediator, in the registry. There you can directly define the CDATA tags inside the XML content stored in the registry. This allows you to define  CDATA inside payload factory mediator.

An example usecase is as below:

PayloadFacroy Mediator:

<?xml version="1.0" encoding="UTF-8"?><payloadFactorymedia-type="xml"><formatkey="conf:/…

Introduction to WSO2 Registry Mounting

This post is based on the common questions raised about registry mounting and how it works etc. Below are the main questions people ask:

1). How mounting works?
2). What is the difference between Config Registry and Governance Registry?
3). Can I use databases other than H2 for Local Registry?
4). What is meant by mount path and target path?
5). Do I need to configure “remoteInstance” URL?
6). What should I use as the cacheId?

So let's start with how to configure a registry mount. When you are configuring the registry mount, you have to add the relevant data source to the master-datasources.xml file. In addition to that, you have to add mounting related configuration into the registry.xml file as well.

In the master-datasources.xml file you have to just configure a JDBC data source by providing JDBC URL, username, password, validation queries, connection optimization parameters, etc. An example data source entry will look like below.

<datasource><name>WSO2CarbonDB_Gov&l…

Manage Solr Data in WSO2 Server

Image
Recently I was checking an issue faced by one of my colleague while automating WSO2 API Manager deployment. There, once the new pack is deployed by pointing to the existing databases, APIM Store didn't show existing APIs at once. It took some time to display all the existing APIs in the Store.

The APIs are retrieved using the Solr based indexing in APIM. Therefore, the main reason for this behavior is that a fresh pack doesn't have existing Solr data and it takes some time to complete the indexing. Until that indexing process is completed, it will not show API in the Store instantly.

To address this, you can follow one of the below approaches:

1). Backup existing Solr data (APIM_HOME/solr/data) from the existing deployment and added it to newly created pack.


2). Externalize Solr data directory. Solr data stored location can be configured via core.properties file located in the APIM_HOME/repository/conf/solr/registry-indexing directory. So you can update core.properties to stor…

Lifecycle Managment with Governance Publisher

Image
WSO2 Governance Registry (WSO2 G-Reg) is a fully open source product for SOA governance. In G-Reg 5.0.0 release, we have introduced a revolutionary enterprise publisher and store for asset management. As I explained in my previous post, the Lifecycle of an asset is one of the critical requirements of enterprise asset management.

G-Reg Publisher Lifecycle Management: 

With WSO2 Governance Registry 5.3.0, we have introduced a new Lifecycle management feature for publisher application as well. After enabling lifecycle management in the publisher, you will be able to see new lifecycle management UI as below.



This lifecycle management can be enabled for one asset type or all the generic asset types(RXT based). If you are enabling this for all the assets, you have to change 'lifecycleMgtViewEnabled' value as true in the asset js file located in the GREG_HOME/repository/deployment/server/jaggeryapps/publisher/extensions/assets/default directory. By default, this publisher based lifecy…

How to clean Registry log (REG_LOG) table

If you are using WSO2 Governance Registry or API Manager product, you might be already aware that all the registry related actions are being logged. This REG_LOG table being read for Solr indexing(store and publisher searching). Based on the REG_LOG table entries we are indexing artifact metadata. However, with the time this table size might grow. So as a maintain step you can clean up obsolete records from that table.

So you can use below query to delete obsolete records from REG_LOG table.

DELETE n1 FROM REG_LOG n1, REG_LOG n2 WHERE n1.REG_LOG_ID < n2.REG_LOG_ID AND n1.REG_PATH = n2.REG_PATH AND n1.REG_TENANT_ID = n2.REG_TENANT_ID;

DELETE FROM REG_LOG WHERE REG_ACTION = 7;

WSO2 Governance Registry Lifecycle transition inputs

Image
WSO2 Governance Registry (WSO2 G-Reg) is a fully open source product for governing SOA deployments, which provides many extension points to ensure your business policies. With G-Reg 5.0.0 release, we have introduced revolutionary UIs for enterprise asset management and discovery. 
The Lifecycle of an asset is one of the critical requirements of enterprise asset management and Lifecycle management is focused on various state changes in a given artifact through different phases. If you want to read more about this, please go through my article on "Governance Framework Extension Points."
So here I am going to talk about, one of the feature enhancements which we added for G-Reg 5.3.0. With G-Reg 5.3.0, we have introduced lifecycle transition input for G-Reg publisher. With lifecycle transition inputs, you will be able to parse custom inputs from a user who is doing lifecycle operation. 
As an example, you have integrated wso2 governance registry with API Management product using…

Service Discovery with WSO2 Governance Registry

This blog post explains about the service discovery capability of WSO2 Governance Registry. If you have heard about UDDI and WS-Discovery, we used those technologies to discover Services during 2009-2013 time.

What is UDDI:

UDDI stands for Universal Description, Discovery, and Integration. It is seen with SOAP and WSDL as one of the three foundation standards of web services. It uses Web Service Definition Language(WSDL) to describe the services.

What is WS-Discovery:

WS-Discovery is a standard protocol for dynamically discovering service endpoints. Using WS-Discovery, service providers multicast and advertise their endpoints with others.

Since most of the modern services are REST based, above two approaches are considered as dead nowadays. Both UDDI and WS-Discovery target for SOAP based services and they are very bulky. In addition to that, industry is moving from Service Registry concept to Asset Store(Governance Center), and people tend to use REST API and Discovery clients.

How Disc…

G-Reg and ESB integration scenarios for Governance

Image
WSO2 Enterprise Service Bus (ESB) or WSO2 Enterprise Integrator(EI) products employs WSO2 Governance Registry for storing configuration elements and resources such as WSDLs, policies, service metadata, etc. By default, WSO2 ESB/EI shipped with embedded Registry, which is entirely based on the WSO2 Governance Registry (G-Reg). Further based on the requirements, you can connect to a remotely running WSO2 Governance Registry using a remote JDBC connection which is known as a ‘JDBC registry mount’.

Other than the Registry/Repository aspect of WSO2 G-Reg, its primary use cases are Design time governance and Runtime governance with seamless lifecycle management. It is known as Governance aspect of WSO2 G-Reg. So with this governance aspect of WSO2 G-Reg, more flexibility is provided for integration with WSO2 ESB/EI.

When integrating WSO2 ESB/EI with WSO2 G-Reg in governance aspect, there are three options available. They are:

1). Share Registry space with both ESB/EI and G-Reg
2). Use G-Re…