Apr 9, 2012

DataPower get WSDL from MPGW - make it work with ?wsdl

I needed to make the GET method work with POST on MPGW (Multiple Protocol Gateway). I made a proxy service which does some WTX COBOL <==> XML mapping ( on that I will expand in another post) over WMQ. The proxy exposed over SOAP.
I wanted to enable the service consumers an option to get the WSDL from the DP on the same URL with the "?wsdl" method. Customer doesn't have WSRR or other registry solution on site.
On the way I encountered on a strange issue in DP when tried to make the GET and POST methods enabled at the same time on the MPG. It just didn't worked at the same time. POST or GET not together.
No error at all, after some investigation of the probe log I noticed the following information message :

"Event Code 0x80e0010e - The configuration has disabled rule processing in one direction.
The configuration has disabled rule processing in one direction. This may be due to an 'unprocessed' rule setting, or a dataflow which is inherently unidirectional, such as HTTP GET transactions which only have databodies in the response path."


The issue was that by default the policy rule can handle only one method at a time like GET or POST and not together. IBM likes to hide stuff.


To handle this issue you need to enable non xml processing on the processing rule under the Objects --> Xml Processing --> Processing Rule --> [Your Rule], set the "Non-XML Processing" to on. This will solve the parallel processing of SOAP (POST) and HTML (GET) in the same policy.





The Solution pattern :


  • Set the MPG back end to dynamic proxy back end type. It need to be dynamic to enable basic Content Base Routing (CBR) on the response flow. One handles the WS request and the other the WSDL. The distinction will be made in the match pattern on the back end URI.

  • Create a Client to Server processing rule which would handle the GET ?wsdl (also the match pattern "*?wsdl|WSDL) request.
    I did simple fetch to the WSDL file from local store, It can be handled differently with registry/repository on site :-). Or it can be evolved to dynamic xslt which will generate WSDL with environment context like the address.
    in the rule you need to set the back end URL to different from the original service so you can match on it in the response rule. I set it to loopback, you need to set the var://service/routing-url = http://127.0.0.1/loopback. 
    Also because no back end processing needed set the var://service/mpgw/skip-backside = 1, by this the rule won't pass the request to the back end at all. loopback pattern.
  • Create the Server to Client rule to handle the WSDL response flow. Nothing special there, only  the match pattern which set to "*loopback". Thus handling only the WSDL requests.
That's it.
Hope it would help someone.





Jan 29, 2012

Biztalk future - it won't going to die soon

I think that in the last two years there was a lot of online BUZZ regarding the Biztalk Server will go out of support.
I believe that this won't happen in the nearest time.
Microsoft can't kill its middleware Integration solution. There are thousands of production Biztalk environments world wide.
Biztalk will stay as a on premise server solution for some time, yes Microsoft roadmap is to move toward the  cloud solution. AppFabric with Service Bus, Integration Services, Cache Service and other services will eventually implement the current Biztalk capabilities, the solution won't be called Biztalk.
Microsoft aims to create a single middleware solution for cloud and On-Premises projects.
Today Microsoft focus is on the cloud. And it will take time , years, to implement Biztalk functionality on the AppFabric cloud solution.
Migration probably won't be smooth but eventually it will work, from what I saw online the migration process won't be able to handle whole applications, only artifacts (Orchestrations, maps, pipelines and ...).
But I am sure that Microsoft will provide the needed support in a reasonable TCO to move from Biztalk Server to the AppFabric next-Generation middleware solution.

Microsoft will continue to the develop and invest in Biztalk Server project till the cloud AppFabric project will have the needed and current Biztalk capabilities.
The Biztalk project will be evolved in a moderate speed and investment.

Biztalk has a great integration features, like:

  • Orchestrations - machine based integration flows, custom XBPEL files. The current .Net developers familiar with the Windows Workflow Foundation (WF). In the last 2010 version you still can't execute the WF on Biztalk runtime engine, but it is part of the product roadmap.
  • PUB/SUB engine - everything in Biztalk is based on the Publish/Subscribe patterns against the MessageBox DB for prof and cons.
    This architecture is a major pitfall for low latency solution. But on the contrary it enables loosely couple integration solutions.
    For low latency you can combine Biztalk map and adapter functianlity with WF in a regular .Net project in VS2010 and above. 
  • Integration by  Windows Azure Connect  with Azure windows services.
  • B2B - EDI, SWIFT
  • BAM
  • BRE
  • ...
A nice recorded presentation from the WPC2011 by Tony Meleg's provides Microsoft long time strategy and commitment for Microsoft's Application Infrastructure future.

In conclusion 

Biztalk will stay in the market for a long time, eventually Biztalk capabilities will be implemented on the Azure AppFabric solution.