Hi, today we're going to take a look at the IBM integration bus version 9,
and specifically an approach to development which is called
patterns-based development.
Patterns-based development accelerates and simplifies
the delivery of integration on the IBM Integration Bus.
Let's start up the Integration Bus Toolkit, and we'll just start with a nice clean workspace.
So, there we are,
we've got a completely empty workspace: no artifacts,
applications, integration services, or libraries developed.
We have the default configuration created, again by the toolkit,
which is the IB9NODE and an empty execution group, so there is nothing deployed
into that runtime integration node. So let's switch to the Pattens Explorer.
We give ourselves a bit more real estate.
And as you can see, what we have
is a very rich set of patterns for doing many different, but common,
integration tasks. The pattern we'll choose today
is to place a service facade (a web service interface)
in front of a WebSphere MQ-enabled application. What we'll simply do is say there are
requesting applications
that will make a web service request to the Integration Bus;
the Integration Bus will then place a message on the provider queue
to the back end MQ application, and will
create and send a response back; a simply acknowledgement in this case,
which is why its a one-way [flow]. So the Patterns Explorer gives us a nice view
of what we are going to create; it also tells us a bit about the solution; there's a
description there,
and it also gives us information about what it is going to create, a number of
different message flows,
and other related tasks to do with that pattern. So, let's create an
instance of this pattern, and we'll just simply call it something like 'testwsmq'.
If we pop that up,
What we actually see here is we are presented with a number of things that we have to do.
These are the points of variation which exist in
every pattern. Now in this particular pattern
a major point of variation, and that is showing up here with the 'x', that we must do
is to actually specify the service interface, i.e. the WSDL
which is going to describe this service. You notice that
all of the other points of variation have got ticks against them,
and as we open some of those we'll see that the toolkit has quite handily
defaulted a lot of values to save us work where we don't need to do it.
The other thing that we see here is some context-based help
so we can go and look at the service information
and get some information about how we might fill that out;
and we have those for each of the pieces. OK.
So the first thing we really want to do here is
we want to go and identify our piece of WSDL
that is going to describe our service. Now, because I'm working from a blank canvas here
what I'm going to do is I'm going to go and create a new library.
Now a library is a construct inside IIB [IBM Integration Bus]
that allows us to create reusable artifacts, and in this case a service interface
would be are you reusable artifact that we might like to use time and time again;
not just in this one application.
So we'll give the library a name, and then we'll go and pick up the WSDL.
Now, in my case it is just out on the file system,
and we'll just navigate to that, and there it is.
Just a demo customer. OK. And if we complete this process, the tool is just
interrogating, say we've got a SOAP binding,
and then we'll hit the OK button, and going away in the background
you can see some things happening there. OK.
So, we want to create that inside our test library;
and what it has done is pulled it in, and
we can see it has created an inline schema
and we can also see from the data portion of it that basically
the request objects and the response objects that describe the operations are inside there.
If we go back to our pattern template, we can say that it is prepopulated now,
and we've got a little 'tick'. Let's just go and take a quick look at the other pieces;
so provider information (where would we put our request message
to our backend MQ application?);
and it's simply defaulted to provider and, you know what,
we'll take that default at this point.
Logging is by default turned off; we'll switch it on; and again we'll take a default to say
we'll place a copy of the input message on the log queue,
and if we go and look at error handling
we'll see that error handling is turned on. OK.
And there is a default error queue again that we could change,
and there's a few other options as well that allow us to separate off,
as a Developer, we might develop in our own schema;
we might choose to put a prefix etc on these things...
OK. So we can see it was generated for us.
But we're basically ready to go; so let's hit the Generate button
and the tool, using the Message Broker flow API,
will actually go and create the artifacts for us,
based on best practice for integration
plus those points of variation that we've configured.
OK. So the generation has completed, and we've got a nice summary report.
So we've got a request flow, and a number of subflows that have been created for us;
and we also have a set of tasks to complete as well.
I.e. we've got to go away and create these queues. OK.
We also obviously want to [deploy] compile and deploy the BAR file, which contains the artifacts
to the runtime broker. So while we're here, with our tasks to complete, let's go out to WebSphere MQ
and let's create those queues that we need
assuming that they're not already there; so there's our provider,
OK, we need a log queue, ...
and we need an error queue.
OK.
Let's go back to out toolkit. We're now in the application development environment;
let's just clean up these things. We're done with the pattern generator now.
And we can go take a look at what actually got generated:
so we've got our WSDL inside out test library; and we've got our message flows.
OK. Let's take a look at the main request flow,
and what you'll see completely built for us, and ready to deploy and test;
if we look at the SOAP input node, what we'll see
is that the tooling has picked up our point of variation
and its preconfigured to use the demo customer WSDL.
It's even gone as far as creating a URI for us as well
and telling us which port that we're actually listening on.
There's a couple other constructs here: there's a flow order construct
and the flow order says please do this first, so I would drive
first I will try and actually deliver the message to the provider queue
and send an acknowledgement back to the calling application
and if that's all successful, then second I will then go down
and I will drive the subflow for logging, and I'll place a copy on the log queue.
The second construct here is a try-catch, and this controls the error handling,
so I am going to try to deliver
and if I get any failure down this route at all,
I will come back and I'll drive the catch terminal and I'll drive the error handling. OK.
So the next thing we'll do without looking anymore deeply
actually at the flow itself, is we'll deploy and test it. As I said,
this flow is ready to go, so if we actually click on
the application that has been created, and we go down and select Test
then we're actually offered the Test Client, and what the Test Client will do
is it will deploy the message flow and associated artifacts
and it will actually then drive the flow with a set of test data.
And you'll see what it's done, because I pointed at the message flow,
it's actually already looking at that SOAP input node, and its done some interrogation
of what you can send to that SOAP input node.
Now, there's a number of operations. Let's look, for example, at the SOAP customer information,
and if we just take a look at what's done for us
we'll see that it actually knows what the input should look like.
It's even gone as far as giving us some default values.
So we'll put something else in and we'll say my name...
and we might say...
my second name.
I we'll leave Middle Name as middle name. So, basically, we can overwrite those values,
and then we can hit the Send button to actually send this stuff in.
OK. Where should we deploy it? Well, we want to deploy it to this integration node
and we deploy it to that execution group, which is a process container. OK.
And its going to go away and start the compilation. It'll ask us if we want to deploy that;
we'll say 'yes thank you very much'.
And its going to go and deploy that message flow out into the runtime.
And its going to start testing: it sent the message in to the
SOAP input node; it sent that SOAP message in.
Its monitored the SOAP reply node,
and it's received an acknowledgement.
And its also taking a look at the queues as well:
so there's a provider queue; so it's monitored that provider queue.
And we can go and look and see that there is our message on that MQ queue,
going to our back-end application. OK.
So its deployed, and run the test, and monitored for the responses as well. OK.
So what's interesting here is things like this: so there is our reply; How did the word
'Accepted' actually get in to the reply?
So if we go back to our request flow, we can look at what the tool has done for us.
It knows what the response looks like. It knows there is a response object with an
acknowledgement in it, because it knows about the WSDL.
And it's simply seen that it's a string
and it has put the word 'Accepted' in there.
Now clearly you'd override that with your own requirements. OK.
If we go and look out on MQ, we'll see the queues out there.
Now our Test Client itself drained the provider queue
so that we could see the response inside the tool.
But we can go and take a look at the log message; so, if we just go and browse these messages
we'll take a look on the log queue here, and what we should see is (we should see)
a copy of our message. OK. That's out on the queue... [drags pane to see message]
And there it is. OK.
So we actually did get a message out on the queue as well,
and we see the response as well, on the provider queue,
with our data in there. OK.
If we look down here in the bottom (I did not open this earlier on)
but there's our deployed message flow, with its deployed library, with its service interface.