Search This Blog

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:

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.

Conclusion

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.

Disclaimer

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

Get link

Facebook

Twitter

Pinterest

Google+

Email

Other Apps

Comments

Post a Comment

Popular Posts

Last week Software AG announced the Trial Version of Webmethods 10.1 had been released. I must admit I've been looking forward to this since the October release note promised they'd be significantly improving their Rest API and Swagger support, specifically:

REST enhancements: Integration Server and Designer now support the ability to read a Swagger specification and automatically generate a REST API descriptor. Additionally, there is support for REST v2 and the OAuth 2.0 Introspection specification. IS can now authorize OAuth2 tokens issued by third-party identity providers like Ping Identity and Okta.
The ability to generate Swagger from a REST service in Webmethods has been around for a while - although it's been far from bug free. I was keen to see if this was resolved, but more importantly I prefer to develop "contract first" so the import capability is a big selling point for me.

This blog covers my first impressions - and sadly some of the issues I've …

I started working in the integration area in 2007 and have worked
on more than a dozen integration projects. I’m now venerable enough to have seen
what was once best practice become old hat, or even (the worst pejorative of
any transformation project) “legacy”. So, what has and what hasn’t changed?
That was the way it was
When I started my integration career Webservices were in
full swing and SOA was close to the peak of the hype cycle. The future was to
be business logic exposed as re-usable services, using open standards such as
WSDL and XML. Open standards were everything, and the standards bodies W3C and OASIS
(Organisation for the Advancement of Standards in Information Systems – if I
remember rightly) were publishing an ever growing canon of WS-* specifications.
The common ones were of course WS-WSDL, and WS-Security; but then came
WS-Eventing, WS-ReliableMessaging, WS-Trust, WS-Policy, WS-Notification,
WS-PolicyAssertions, WS-Discovery, WS-Addressing, WS-Topics, WS-Enumeration…

A decade after working on my first Integration project, I’ve
been reflecting on what changed and what hasn’t. My last
post focussed on how things were then, and what technology and techniques have
fallen away; but there is as much common as there is different. Much “best
practice” in 2007 is still good now, and sadly some of the challenges I saw
then are still to be truly addressed.
Open standards
A big theme of the early 2000s was a push to use open
standards - although older colleagues may point out that CORBA predated this.
In my “what changed” blog I took a rather tongue in cheek attitude to the
myriad of WS-* standards; but although this trend got a little carried away, it
was essentially a good thing.
Back then committees decided standards, now a more Darwinian
“survival of the fittest” Open Source approach has taken hold. Standards are
still open but rather than a compromise several potentials emerge, then one -
or perhaps two - win out. This was seen when Swagger,
and to a l…