Sunday, July 15, 2018

Moving from Selenium to Protractor for Web Automation

99x Technology invests heavily in Quality Assurance, and this one of the reasons why the company has been able to carve out a name as a trusted product engineering company. The brunt of the QA work at 99x is achieved using automation, specifically protractor. 

As someone who is familiar with Selenium,TestNG and Java, I found myself a little intimidated at the prospect of learning a new stack including a new language(javascript) but to my delight I found the experience to be relatively pain-free and intuitive. In hindsight, I can clearly see the reasons as to why making the shift from Selenium to protractor makes sense.The main reasons as I see it are,

The fact that Angular and JS is taking over the web
As a technology invented and backed by Google, it was just a matter of time before AngularJS piggy backed into becoming the dominant web application technology around. Naturally, as Protractor is custom built to test angular apps, it makes sense to use it to test angular apps.  

Not having to meddle around with the web drivers 
Downloading the latest greatest web driver for each browser being tested and then setting up the driver in code and all the other steps that follow are pains associated with Selenium. As protractor is built as an API encapsulating selenium, it takes care of most of these pains. All you have to do is run the command to update and start the drivers and the API takes care of the rest. 

Not having to meddle around browser weights(sort of!)
Unlike Selenium Protractor provides is hard-wired for implicit weights for elements, it also supports explicit waits in the way of actions and browser sleep operations.

The backing of a Healthy community
Personally, i found the protractor community to be more active compared to that of Selenium’s. Maybe this is because its relatively. As protractor is built as an Node.JS package, it benefits from the NPM community. You can easily find extensions like reporters and data providers.    

....

Moving on, when making the switch(given you’re moving from java to javascript,  I did), give special attention the fact that JS is an asynchronous language, meaning, the language may process two program statements inside a code block parallelly as opposed to processing them sequentially as we expect in Java. The protractor API hides the complexities of working with the asynchronous nature of JS whenever you’re performing an action on the browser but whenever you’re receiving data from the browser to the test code, you need to explicitly handle the logic required to handle the parallelism, this is done through a mechanism named promises.

I’ve put together a project[1] that automates a set of test-cases for a banking app put up by way2automation tutorials site. The project uses most features available in protractor as well as some of the main functionality of jasmine and some of its extensions such as the html/screenshot reporter. The project embeds protractor as node module, therefore it can be executed as follows(not the project is expected to be run on windows).


npm run webdriver-update
npm run webdriver-start
npm run start





Sunday, December 24, 2017

In-container unit tests (Docker TestNG integration)


With the advent of containerization of applications and the proliferation of micro-services, there arise a need to test containers similar to the way jar’s(java libraries) are tested using unit testing mechanisms. The example below demonstrates one such method that unitizes an environmental variable to trigger a TestNG test suite from outside a container. 

1.  Put in the test trigger code in your applications entry point as shown below,




2. Create a container consisting your application jar file(s), make sure all dependencies are available inside the container. In the example project the testng.xml file and a jar consisting of the application and its dependencies are copied into the container.



3.  Run the container passing in the environmental variable as show below,




Find the example code base here[1]. Note that the container is made problematically using the docker main plugin. 

Tuesday, September 19, 2017

An API Design Capabilities Comparison: Apigee Edge Vs. WSO2 API Cloud

Disclaimer: the information and views presented in this document may not be the same as those endorsed by the owners of the products and should be considered as an opinion of an independent analyst.  


Download this technical paper in PDF format, link.

Terminology Map

This sections is meant to debunk a few vendor specific terms,

WSO2 Term
Apigee Term
API
API proxy
Resource
Flow
Message Mediation Policy
Policy
Throttle Policy
Policy
Store
Developer Services Portal
Publisher and Admin portal
Management UI

Introduction

It is justifiable to say that an API’s success or failure is determined by the level of adoption and use it sees, therefore it is also fair to say that API creators should invest a considerable amount of their efforts to ensure they get the developer experience of the API right.

Ovum Decision Matrix: Selecting an Integration PaaS (iPaaS) Solution, 2015-2016 predicts the API Management space to grow at a rate of 40% to reach a market valuation of 940m by the end of 2019[1]. The mediation/transformation capabilities found in many API Management solutions are a subset of those provided in integration products such as ESB’s, therefore it should not come as a surprise that over the years API Management products be it on premise solutions or cloud deployments have started porching into the integration market. This view is reflected in Ovum Decision Matrix: Selecting an API Management Solution, 2016-2017 report, where they predict API Management solutions will need to provide an end to end experience that capture the value proposition provided by middleware stack providers.[2]

The objective of this document is to provide a comparison of the API design capabilities provided by two prominent API management services in the cloud, namely Apigee Edge and WSO2 API Cloud.

Both providers have had presence in the API Management space for a considerable amount of time and have made a name for their offerings. Apigee introduced their solution as a cloud offering prior to moving into the on-premise domain, as opposed to WSO2 who ventured into API Management space as an extension to its on premise middleware product portfolio, they started offering the solution in the cloud from 2015[7].    

Method

The research component required for created this document was carried out with the use of free trials provided by the two vendors. Both vendors provide a full access trial that allows users to test drive the product for a predefined period. At the time of writing, WSO2 API Cloud uses an API Manager 2.X build and Apigee Edge, a 17.X build.

Capabilities of each offering was identified by referring publicly available information and through hands on experimentation on the products.

Data-sheet Comparison

Before looking into a few key design capabilities of each offering in detail it’s worthwhile to compare the offerings at a API design datasheet level.


Capability
Apigee Edge
WSO2 API Cloud
Swagger support
Supported
Supported
SOAP endpoints
Supported
Supported
API resource definitions
Supported
Supported
Design validation/testing
Supported
Limited Support
Design import and export
Supported
Supported
Versioning
Supported
Supported
API Proxy path mediation logic definition
Supported
Supported
Backend path mediation logic definition
Supported
Limited Support
Mediation extension
Supported
Supported
Graphical Mediation logic editor
Supported
Limited Support
Security
Supported, requires setting up
Supported
Traffic management
Supported
Supported
REST API support for design functionality
Supported
Supported
Backend mocking
Supported
Supported

Deep Dive: capabilities comparison

The proceeding subsections compares a few key API design aspects of the two offerings.

Swagger Support

In the context of API Management, Swagger support plays two roles, first it allows API publishers to use predefined definitions as a starting point in the publication process. Secondly, it allows Swagger definitions of published API’s to act as a starting point in the discovery and adoption process. Many API management solutions provide functionality dedicated to these very requirements, this is also the case for the two offerings being evaluated.


WSO2 API Cloud
Apigee Edge
  • Publishers may start the API Creation process utilizing a Swagger JSON upload or a hosted Swagger JSON URL.
  • API attributes such as resources, context and version are extrapolated from the provided swagger definition.
  • Allows the publisher to break into an embedded Swagger editor at design time to define resources etc using YAML.
  • The swagger console in the developer portal gets populated with the content of the definition utilized at design time.
  • Publishers may start the API Proxy creation process utilizing a Swagger YAML/JSON upload or a hosted YAML/JSON URL.
  • Attributes such as flows, context and backend endpoint are extrapolated from the provided Swagger definition.
  • Publishers may define the specifications in the specs section of the management UI prior to creation of a new API Proxy.

Mediation Time Logic Definition

As discussed at the start of this document, API management solutions are venturing into the integration space. The ability to define simple mediation time logic has become a capability many API Management solutions provide.

Both products offer mediation capabilities and mechanisms to define the mediation logic at API design time. In the case of apigee a rich graphical editor is offered to the API publisher, whereas the WSO2 API Cloud provides unrestricted access to many of the mediation capabilities of its mediation engine with the use of message mediation policies.


WSO2 API Cloud
Apigee Edge
  • Publishers may utilize pre configured Message Mediation Policies that cover some frequently needed scenarios such as XML to JSON conversion and vise versa.
  • Publishers may attach custom Message Mediation Policies that are written in WSO2’s mediation language.
  • Message Mediation Policies may be attached to the API’s Request or Response flows.
  • Backend endpoint request and response mediation logic may be put in using custom Message Mediation Policies.
  • Policies are provided for frequently needed scenarios such as XML to JSON conversion and extracting content from HTTP header/body components.
  • Mediation extensions are supported with java script.
  • Mediation time logic maybe attached to Flows, which include, API request and response paths, backend request and response paths as well as individual resources of an API.  
 

Security

Securing API behind an access control layer is one of the key requirements any potential consumer of such a solution would have. In the space API Management this is achieved using Oauth and its options provided through grant types. The grant types an API should support should be decided based on the manner in which the API is expected to be consumed, as such API Management solutions should provide mechanism to define these attributes at API design time.

Apart from securing access to the API, it’s common for API management solutions to provide, transit security and last mile security capabilities.

Both offerings provide comprehensive security options.

WSO2 API Cloud
Apigee Edge
  • The publishers are allowed to select oauth options per resource.
  • The solution inherently supports password and client credential grants, others maybe be availed by explicitly calling the oauth API endpoint.  
  • Management API are secured in Oauth and in some cases basic authentication.
  • Transient API calls are secured with TLS.
  • Solution supports API Key and Oauth as security mechanisms.
  • Security mechanisms maybe attached to flows.
  • Endpoints required for oauth should be created/deployed in the environment being used(refer apigee documentation sample[8]).  
  • Management API are secured with basic authentication(can be configured to use oauth)
  • Last mile and transient security is provided.

 

Traffic Management

Regulating the flow of invocations to API is another key requirement of those who seek to employ API Management solutions. The regulation mechanisms may be needed to control the access to the API as well as to ensure the access policies of backend services are not violated.

Both offerings provide a comprehensive set of traffic management capabilities.   

WSO2 API Cloud
Apigee Edge
  • Publishers are allowed to attach predefined throttling policies at API, application or resource level.
  • Publishers with Administrative permissions may create custom throttling policies editor found in the admin dashboard.
  • Advanced traffic management requirements such as spike arrest or intelligence based throttling scenarios can be accommodated using custom rules, written in WSO2 stream analysis language SiddhiQL[3](ATM, this feature is only available in the on premise version of the solution).
  • Response caching can be enabled at API level, to ease the burden on the backend services and increase client response times.
  • Traffic decision measure can be changed from number or requests to bandwidth if required.
  • Quota policies can be attached to multiple points such as API, API keys, access tokens and developers.
  • Spike Arrest policies can be attached to flows to smooth out access to API.
  • Advanced quota scenarios may be constructed using the policy configuration[4].
  • Distributed quota counters supported.
  • Provides concurrent rate limit policies to regulate the flow to backend endpoints managed by the solution.
  • Multiple response related caching capabilities are provided as policies.  

Design Experience

The API design experience is considerably different between the two offerings.

Apigee Edge
Apigee provides an extensive collection of policies related to mediation time logic definition, this aspect of the product pushes its proposition towards that of an integration product such as a ESB. To accommodate its extensive palette of policies in a meaningful way the product provides a centralized API editor.

The publisher first creates a skeleton API design either utilizing a Swagger definition or using the API proxy wizard(figure 1). Once the skeleton API design is in place it may be filled in using the editor(figure 2). The editor provides a graphical representation of the API’s mediation flow, underlying XML configuration and the palette of policies that can be attached to the API’s flows as needed. The design may be validated by deployment and trace capabilities provided. Once the design is validated it may be packaged into a product to be made available in the Developer Services Portal(developer portal).

design1.png
figure 1

design2.png
Figure 2

WSO2 API Cloud
The design experience here is comparatively more guided, in the sense the API publisher must follow three predefined steps;  design, implement and manage when creating an API(figure 3). At each step the publisher makes decisions pertaining to the areas of design the steps represent. Swagger editor is integrated to the design stage allowing the publisher to access its capabilities in a way which is not possible with Apigee’s offering.
design3.png
Figure 3

Conclusion

One of the key conceptual differences between the two offerings is in the way some API management aspects such as security, traffic and mediation are defined and offered for the API publishers consumption. Apigee does a weak separation between these concepts at design time allowing the API publisher to use them as components of equal standing when designing API. Further they direct the API publisher’s focus to the definition of the API mediation logic, providing a rich editor. The weak conceptual separation of these areas is also reflected in their terminology where atomic components belonging to seemingly unrelated areas of API design, such as security, traffic and mediation are all referred by the umbrella term “policy”. This weak separation provides simplicity in API mediation design from a publisher’s perspective, and further strengthens the offerings potential as an integration crossover solution.

WSO2 API Cloud, provides a rich set of functional capabilities that align with traditional API Management offerings. Bridging the chasm of a full middleware stack seem not to be an imperative here, as such the offering is on the point and focused on API Management specific needs.        

In the case of Apigee Edge, the publisher is provided more flexibility in design and capabilities that cross over to the integration space, he or she is allowed to make more design time decisions, however this flexibility may come at the price of unwarranted complexity for simple API design needs a SME/SMB or a startup is likely to have.

There are no hard and fast winners here, rather the two solutions, with their capabilities and design are suited for different requirements and different types of consumers. For those who require rich mediation logic definition and validation, fine grain control over the design, Apigee Edge may be the better of the two options. If however, the requirements are simpler and are more inline with traditional API Management practices, from a pure API design perspective it might make more sense to go with the WSO2 API Cloud.


Find out more information about the two products and take them for a test driver here[5][6].

Appendix

WSO2 API Cloud Pricing

The prices were extrapolated on the 18th of July 2017 from the official product website. The plan prices are in USD. Apart from the prices listed below, there is a baseline cost of $498 for those who require VPN access to the deployment datacenter.

Plan
Starter
Getting Traction
Medium
Large
Extra-large
Portal users
100
2000
7000
unlimited
unlimited
Maximum calls per day
250,000
700,000
2,000,000
10,000,000
50,000,000
Maximum calls per second
10
25
70
300
1000
Gateway deployment zone(GCP) options
US East only
In one of the following zones,

Canada, US East, US West, Brazil (São Paulo), EU (Ireland), EU (Frankfurt), Singapore, Tokyo, Sydney, Seoul, Mumbai
Upto three different zones from the following list,

Canada, US East, US West, Brazil (São Paulo), EU (Ireland), EU (Frankfurt), Singapore, Tokyo, Sydney, Seoul, Mumbai
Upto three different zones from the following list,

Canada, US East, US West, Brazil (São Paulo), EU (Ireland), EU (Frankfurt), Singapore, Tokyo, Sydney, Seoul, Mumbai
Upto three different zones from the following list,

Canada, US East, US West, Brazil (São Paulo), EU (Ireland), EU (Frankfurt), Singapore, Tokyo, Sydney, Seoul, Mumbai
Monetization capabilities
No
Yes
Yes
Yes
Yes
Plan cost per month
$129
$298
$698
$2,980
$9,980

Reference List


[1]  - Ovum Decision Matrix: Selecting an Integration PaaS (iPaaS) Solution, 2015-2016

[2] - Ovum Decision Matrix: Selecting an API Management Solution, 2016-2017

[3] - SiddhiQL Guide 3.1

[4] - Quota policy

[5] - What is Apigee Edge?

[6] - WSO2 API Cloud Documentation


[8] - Secure an API with OAuth