Webmethods IS 10.2 - What’s new

Webmethods released v10.2 last month – and I thought I’d have a look at what it offers. Software AG are at pains to point out that this is not a stable release but an “innovation” release. I know this because the installer had a disclaimer which I had to accept saying that I understood it was an innovation release and thus would only have a short support period. I also know this because before I even got as far as the installer I had to email SAG to get special permission to download it! This made me wonder if they were trying to set expectations that it might be buggy.

Honestly my main interest area at the moment is the somewhat immature REST API support within Webmethods Integration Server, so this post mostly focuses on this area. SAG are also claiming a lot of changes in the Portal and Gateway products, but I’ve not yet had a play so those might need to be another post. 

What has changed...

To assess the changes here, I've mostly looked at what is new in the release notes, which are available in the Tech Community site (warning: these are also hidden behind credentials – just to further demonstrate how far this is from Open Source competitors: not even the documentation is freely available).

Swagger UI

The first mention of anything REST related came in at number 4 in the “Release Highlights” section Release Note:
  • Integration Server supports the Swagger format for describing REST APIs. Software AG Designer displays REST API descriptors (Swagger documents) using an embedded Swagger UI.

Given this high billing I was hoping this was something really nice in terms of dealing with Swagger but sadly – as far as I can tell – this means the Swagger tab in the rad (Rest API Descriptor) is now coloured in, rather than how it was in 10.1 where it is just a plain text file. 
Swagger Tab in 10.1
It’s read only and there don’t seem to be any editor options – although I’d not want one once it was imported admittedly. For editing swaggers before import my preference is still the Intelli-J Swagger plugin – as the online swagger editor is a pain to integrate with version control.
Swagger Tab in 10.2

Swagger import

One of the main pain points we’ve faced since using the Swagger Import functionality (first discussed in my Webmethods 10.1 First Impressions blog) was the fact that you can’t have two Swaggers which start with the same URL part for example:
  • accounts.yaml contains the definition for the /users/{personId}/accounts
  • order.yaml contains the definition for /users/{personId}/orders
As an API designer I like this as it means we can break up two APIs which focus on different data and are not really related but still maintain a naming convention in the REST URLs which tie them back to the subject they related to. Sadly in 10.1 this didn’t work so we ended up doing something more akin to:
  • accounts.yaml contains the definition for /accounts?personId={id}
  • order.yaml contains the definition for /orders?personId={id}

Both are valid, but it was an annoying constraint to how we wanted to structure our APIs. To test this I created a new “/pet/{breed}/toys” API based on the http://swagger.io Petstore and imported both, it seems to work as claimed.

What has not changed…

Although not discussed in the Release Note, I thought I'd check some of our annoyances or known issues with 10.2 to see if these bugs had been addressed in this major release.

XML Support

In my previous post on 10.1 I noted that both the XML and JSON data structures Webmethods returned after importing a Swagger file weren’t in line with the Swagger spec – although for different reasons.
  • JSON response didn’t support Arrays correctly
  • XML elements were not named correctly
The JSON issue was fixed in 10.2 Fixpack 2 (PIE-47714) - which I noted in the blog update, but what is astonishing is that the XML returned is STILL INCORRECT. The "textbook" answer when calling the GET /pet API from Swagger.io is:
Correct XML response

When calling Webmethods it looks like this (I hard coded the same values as the swagger.io example):
Incorrect XML
I know XML isn't that cool anymore - and honestly it doesn't impact any of my work at the moment but it still feels odd that something this wrong is still in the product over 12 months after 10.0 first introduced this functionality.

Data Validation

One of the most annoying things about the Webmethods server is that although each flows has a “Validate Input” and “Validate Output” tick box, these appear to be lacking a lot. Swagger offers a host of options for defining types from simple strong typing (String, Int, Boolean) to more complex including formats (int64, date-time) and additional controls (minLength/minLength for strings, minimum/maximum for numbers, enums and even regEx patterns). This has caused a lot of issues in the past so I ran a few tests to see how 10.2 works - again using the Petstore example.

In GET /pet/{petId}, petId is defined as an integer, in int64 format
Shown in the new Swagger UI

Webmethods interprets this as a java long – and interprets the value 1 (in the path /pet/1) as a string “1” so fails mismatch.

Next trying to validate a payload (PUT /pet), Webmethods complains that photoUrls is missing (which is really odd as it's obviously false - I think this is an issue with String lists)
Webmethods rejecting an input because a present field was absent
At this point I gave up trying different validations as even the simple validations weren't working.


Webmethods IS 10.2 offers a few tweaks to the REST API and Swagger support but nothing like what one might hope from a true innovation release. 

Webmethods support for REST is still behind the curve and needs to catch up. APIs are by far the most popular pattern for real-time integration at present and Swagger has over the last four years emerged as the industry leader (even if some Mule fans might still argue for RAML). 

For existing customers focusing on REST APIs this doesn’t wet the appetite for the 10.3 “stable release”, so I’d not rush to upgrade. For potential new customers looking for an Integration Platform, Webmethods is still a long way behind the true innovators who are pushing the way in API led architecture.


My postings reflect my own views and do not necessarily represent the views of my employer.

For more by me follow me on Twitter @JAGLees