Custom Rules

Also custom throttling policies can be configured using the
scripting language Siddhi. You can use the following keys to define the policy:
resourceKey, userId, apiContext, apiVersion, appTenant, apiTenant, appId

Subscription Tiers

It will also be easier to edit the subscription tiers and to
add tiers.

This adds a lot of new possible use cases to the throttling
possibilities of the api manager. The Message Broker and Complex Event
Processor components are used to implement the traffic manager.

The Siddhi syntax is very technical of course but it is a
good step.

Log Analyzer

The log analyzer is added and is especially usefull when you
are not able to login to the server yourself. This can be the case in a
multi-tenant cloud environment.

You are for example able to view the number of errors and
warnings of the application.

I am wondering who usefull this feature is in standalone
mode.

API Store look-and-feel

The API Store has a new theme and looks better. Some screen
shots are shown below.

APIs

Applications

For the applications you are able to select the possible
grant types fort he token generation of that application.

Analytics

Configuring analytics with API Manager is easy when you use
the analytics server package of the download page of API Manager. Then you just
have to set Enable to true within the api-manager.xml configuration file. I
think it will be more complex when you want to use an existing DAS or BAM
server.

Batch statistics

There has been added some more statistics on the usage of
the APIs.

Geolocation based statistics is also possible to be configured.

Realtime analytics

It is also possible to configure realtime analytics and to
receive mails when something extraordinary happens. Note that the admin and
Publisher/Store possibilities differ. There are more possible settings as
admin.

Notifications

A client recently asked if he could receive mails when new
api versions are available. Well WSO2 has added this feature. For now you have
to configure that within some configuration files and not through a nice UI,
and only a notification is sent when a new api version is available. However
the first step is taken to implement more notifications (for example when an
api will become obsolete or deprecated).

So this were some of the most important features added to the
product. Will keep you informed in case i tried some more!

2016/08/23

Introduction

Testability is one of the underestimated qualities of
software. This is also the case for WSO2 ESB projects. However it is important
to design the integrations for testability and this starts with the way you
setup the proxies. This blog gives some guidelines which you can use to design
for testability.

Sequences

Sequences are a way in WSO2 to group Mediators. A proxy has by
default an in-Sequence, out-sequence and optionally an error-sequence. These
sequences can be split up in sub-sequences and this is a good way for reuse,
but also a way to split up the design. A proxy usually contains the following
functional parts:

Validation

Transformation

Sending to an endpoint

These parts can be put in separate sequences. This has the
advantage that the part scan be reused in other proxies. This is also the way
to enable testing for these parts.

Design for testability

The sequences are the basis for the testability of WSO2 ESB
proxies. The following design guidelines and steps can be used for testing your
proxies.

Configure separate
testable parts within a separate sequence
A good guideline in splitting is that the parts should be as independant
as possible from other parts. Good examples are: input validation, data
transformation, sending a message to an endpoint, a step within an
iteration.

Define a separate
developer studio project for the test
proxies
This will be the proxies that will contain a testable sequence and can be
called from soapUI for example. This way also the test package can be
deployed separately. This way the test project is not deployed on
production.

Define a soapUI project
for testing the component
It is wise to define a separate soapUI project for each component (WSO2
proxy) you want to test. Note that this can also be used within a
Continuous Integration environment for automatic testing.

Example

The following is an example in which a data transformation
is tested.

Step 1 – Define data
transformation in a separate sequence

Step 2 – Define separate
ESB project with test proxy

Note that the sequence is referenced and the result of the
sequence is returned with respond
mediator.
This result can be checked within soapUI using Asserts later on.

Step 3 - Define a
soapUI project with test cases

In the request message put a soap message as expected by the
sequence. Note that the ESB uses soap as its common message format within the
mediation. The response can be checked with assertions.

Request

Response

Conclusion

The sequence split can be used to configure testable parts
within a WSO2 ESB implementation.

This may not always be easy todo but hopefully you can use
it to test your ESB implementations.
Feel free to comment on this blog ! All feedback is welcome

2016/05/23

One of the features i missed within the WSO2 Developer Studio was a data mapper.
We had to write our own XSLT or PayloadFactory within the product.
But everything is going to change with the release of ESB 5.0.0 !

A very good blog indeed. However when i tried the new developer studio, i was somehow disappointed. I am positive about the fact that the Mapper is a real resource (even project) now. But i miss a lot of features (like for example XPath functions, if-then-else-construct, constraints) within the mapper.

As you can see from the picture below, only the following operators are supported:

Concat

Split

LowerCase

UpperCase

And when you investigate the generated project files, you will notice that JScript? is generated to do the actual mapping.

So my first impression is disappointed but it is a good start ! Hopefully new features and operations will be added soon, because at the moment i doubt if it is production ready.

2016/02/26

Introduction

Unfortunately i did not went to the WSO2 Conference in Asia but i went through the presentations and this blog item describes some interesting topics i came accross.

There were a lot of different tracks:

API Management

Cloud

Strategy

Integration'

Security

Governance

Architecture

Analytics

DevOps

Internet of Things (IoT)

API

API (Management) is a hot topic. Almost all reference architectures use APIs to expose functionality, either to mobile apps or other apps. It is used within Microservices as contracts, it is used in connected enterprises that want to expose their APIs into the API economy system and it is used internally to manage and govern services.

IoT

Internet of Things is a also a big thing, so also at the WSO2 conference.

Especially the Machine Learner becomes more interesting when "R" is integrated.

Cloud Offerings

Managed Cloud

One of the new cloud offerings of WSO2 is Managed Cloud. As the name suggests, your WSO2 environment is managed by WSO2. The environment is placed in the Amazon VPC cloud. This can be a viable solution for organisations how can not manage their environment themselves.
The regions that are supported: US East, US West, Asia Pacific, South America and Europe (where?).

Public Cloud

Cloud offering that offers WSO2 products in the public cloud. Currently only API Manager and App Manager (Beta) available. Will be extended with Identity, Device and Analytics platforms.