Ensemble Best Integration Software in the market? Not really...

Some weeks ago I was searching something with Big G (I don't remember exactly what), and I found this news: Report recognizes Ensemble as best Integration Software of the market (the news is in portuguese, and I just adapted the title). This really surprised me! I'm not saying Ensemble is a bad software, but the fact is, that it is faaar from being what I would like to work with (OK, there are parts of it that are reaaaally terrible).

I followed the link, and after I have read the page, I just realized that this, as many news calls, is (at least) incomplete. Lets to the facts: A report really pointed this 'leadership' of Ensemble. However, the report aims only for american Healthcare IT business, which is much more restrict than the term 'of the market' means.

The company which published this report is KLAS, which in their words "is the only research and consulting firm specializing in monitoring and reporting the performance of healthcare’s information technology (HIT) vendors". The report is not completely available (at least, not free at the site), but you can get a sample of it here.

As it was done, the result of this report didn't surprised me that much. Caché (and therefore, Ensemble, which is built upon it) is a very strong player in the market of Healthcare IT, inherited from MUMPS. Although Intersystems doesn't like to mention it. Caché is an implementation of MUMPS (with some new features, but the 'spirit' is the same).

IMHO, if this report was made not focusing this specific market, Ensemble would not be that well. I don't have data to confirm this, so if someone knows some reliable data, tell me! (but please, I don't want those 'white papers' from their own company, which is probably written by marketing division)

Web Services with Caché/Ensemble - The Quest - chpt 3

And this is the end of trilogy...

As I said at the end of last post, the chapter 2, when I was writing the SOAP-Body manually, the requisition message was correctly understood by the Web Service. However, for some unknown reasons, the response message was not returning correctly to my code in Caché Object Script. At first, I thought it wasn't working at all, but after I analyzed the TCP stream with a sniffer, I realized that the Web Service was returning correclty. The problem was with Caché/Ensemble, who didn't understand the answer message.

Wondering if the problem wasn't with my modifications, I tested all the WS Client classes without any modifications, but the error was the same. Conclusion: all work so far was for nothing. So, after analyzing Caché's source, and through some little clues the error on screen, I realized that Caché was giving error because it tried to instantiate a class based in WS answer message, but it failed:


(an example of a response message, informing the request was correctly processed)

By then, tired of navigating through source code and bad written documentation, I decided to went down: since I the Caché's %SOAP package could not work fine with the given Web Service, I was going down in the protocol stack, to make it work. Caché doesn't have 'native' classes to deal straight with HTTP (at least, I didn't find any), but Ensemble has an HTTP "Adapter".

(One parenthesis: Adapters in Ensemble are pieces of software which have the function of connecting Ensemble with other systems/technologies. The documentation on this Adapters is really bad, as an example, in this page listing the Adapters, the HTTP is not even listed, and a lot of Adapters there, simply doesn't exist here, in my installation. Freaking...)

After a little testing, I discovered that I was not able to use HTTP Adapter with the Web Service, because this Adapter doesn't let me set a header SOAPAction, in HTTP headers, which is mandatory for this Web Service to work.

As I couldn't use HTTP classes, I went one step below in protocol stack, and use TCP. Ensemble's TCP Adapter is nothing more than a wrapper for Caché's Socket classes, something I already talked about in two previous posts, here (about client sockets) and here (about server sockets).


(protocol stack - almost at IP level =P )

The good thing in using TCP is that you have control over everything, of the HTTP headers, the SOAP XML message, etc... The bad thing is that in order to use it, besides you must understand a great part of all this stuff, you have to write all manually. But as the Caché/Ensemble tools availables were just giving me headache (and errors), I had not much choice. XD

Take a look how it ended (more or less, here I simplified some stuff):



Finally, with a horrible code and using some anti-patterns, all worked. And all that with Ensemble, which, here, some call "Integrator"... I wonder if it wasn't...

Web Services with Caché/Ensemble - The Quest - chpt 2

And the quest continues...

I had based my implementation of all internal stuff of Ensemble
at previous Web Service/WSDL the third-party company gave me. (If you wanna know what stuff I mean, it's BPEL e Ensemble's "Business Operations".)

With the previous WSDL, the Caché's WS Client wizard generated all the structures as classes, i.e., if I had to send an structure "Person", I would have a generated class "Person", with its properties "Name", "Age", etc..., and the method's parameter would be an instance of this class. However, with the new WSDL, the wizard (I dont know why) generated the methods with each property of the structure as a separated parameter. If before it was:

updatePerson(p as Person)

Now it generated:

updatePerson(name as %String, age as %Integer, ...)

And OF COURSE it broke down all my previous work. For me not to have to refactor all other classes, I thought it would be better to change manually the classes generated by the wizard, adapting them for the classes I had.

So, I continued my quest, changing the Web Client class generated:

(before)

(after)

Well, as naive as someone can be, I thought just this would work. I compiled and tested... and didnt work. To not extend the description of my struggle, I found out that with my changes, it was not writing correctly the Body of the SOAP Envelope, as the Web Service expected, with the namespaces correctly declared.

Looking for some solution, I saw the property "WriteSOAPBodyMethod" from the class %SOAP.WebBase, which is superclass of %SOAP.WebClient. This property allows us to define a method to write a custom Body for a SOAP message.

Using it, we have:

(writing custom SOAP-Body - advice: do it as last solution)

With this little "trick", I finally got all my other code intact and working, and it really called the Web Service correctly. But... there was a catch, always a catch...

The quest was not over yet...

To be continued.

Web Services with Caché/Ensemble - The Quest - chpt 1

I have been creating SOAP Web Services with Caché/Ensemble for some time now, and it is very easy, it is as easy as use an annotation with Java, the difference is that you have to extend a class (not a big problem, since Caché supports multiple inheritance) besides annotating the method you want to expose as a service. So, I thought that it would be nice and easy to use Caché/Ensemble as a Web Service client. I was wrong.

It all started when I finally got in hands the WSDL describing some services from a software the company had purchased. These services were needed to allow ours systems to integrate with the new software (which is almost a black box to us).

Since I had made some tests creating Web Service clients for another services and WSDLs, I was pretty confident it would be easy. Too wrong, I was, as Master Yoda would say. Using the WS Client generator Wizard, I just got an error screen. Unfortunately, as you can see below, Caché/Ensemble didn't give me quite nice and enough information, so I got some doubts: the WSDL I got from the third-party software-house was broken/wrong/f***ed up, or Caché just doesn't understand some stuff? (At this point, both hypothesis had the same probabilites to me.)


(Screen with WS client generator wizard error)

So, I thought I'd test the Web Service using soapUI, a program made with Java, that allows you to test SOAP Web Services. I talked about it in last post.

Using soapUI, I could not only create the correct structure of SOAP messages, but also execute the service. This led me the conclusion that there were something wrong with Caché's wizard. As I am a curious person, I tried to figure out what was causing trouble in that WSDL. After half day lost, comparing it with other WSDLs and navigating into specs, the answer finally arised: the request message had two elements, when it usually have just one (usually the message object itself):


(the piece of WSDL which was causing me trouble)

I just erased the second element tag from the message, and the wizard worked! I felt relief, since in this WSDL there were other methods (which didn't cause me problems), and the wizard just stopped when it encountered an error. Unfortunately, my relief didn't last long...

With an older version of this Web Service (one that was given to me during the third-party company development), Caché's WS Client wizard worked well, so I had all my implementation based in it. Of course I was expecting some changes, but I didn't thought there were so many (and so big)... I was wrong, very wrong...

To be continued...

soapUI

In this post I'll talk about a very usefull software I usually use, specially when I have to test SOAP Web Services. The software is called soapUI, and is open-source, with an option of paying for support. Info about installation and first steps is here.

So, what can you do with this program?

Given a WSDL, it will create for you XML request messages, that you can fill up with some data, and submit it to the Web Service, and see the resulting XML response.

Since it is very easy to use, and the getting started guide in the site is quite easy to understand, I wont spend so much time here. Just a few screens:


(Adding a wsdl to a project)


(The XML request message generated)


(After requesting a service, with the XML response message)

Now, just install, test and have fun =D.