Santosh Benjamin's Weblog

Adventures with AppFabric, BizTalk & Clouds

MockingBird Futures – Mock BizTalk Adapters

with 2 comments


MockingBird v2 has almost reached RTM. Just a few more days to make some final touches and it will be ready. The team has been discussing how to take it further and one thing that’s been on my mind for a long time is the topic of mock BizTalk adapters. What I would like to do is write some adapters with the WCF LOB Adapter SDK that link up with MockingBird’s simulation engine so we can then simulate various protocols such as SQL, Oracle, MSMQ, MQSeries etc.

The first question that anyone would ask me is “Why? “. Currently MockingBird works decently as a receiver from BizTalk in one way and solicit response mode. (It also supports duplex channels). If you have a one way message from BizTalk or a solicit response, then all you need is to replace the URL of the endpoint with the MB url and with the right config, the system will send back the messages you were expecting. So, why do we need to mock an adapter when we can simply avail of the WCF-Custom adapter?

While the first thing that comes to mind is that MB only handles the send side and does nothing on the receive side, i do think that there are many other reasons to go down the adapter route (on both the send and receive sides)

For the send side

  1. Adapters will allow us to manipulate & use context properties. For situations where transport level correlation is being used (MQSeries, MSMQ etc), the adapter will let us force copy correlation identifiers to the response. Without this, we would need to have a queue listener that understood the MQ/MSMQ protocols and set properties accordingly.
  2. Adapters will allow us to simulate transactional behaviour.
  3. Minimizes the ‘intrusion footprint’ of the tool. Currently even if you were targeting SQL you would need to switch to WCF Custom and make a lot more binding changes. If we could adhere to the SQL adapter properties, it would reduce the amount of work. In fact all we should require is a change of url (eg: mbsql:// )
  4. If an application interface doesn’t support web services, then piggy-backing on WCF LOB adapters will allow us to mock that system (assuming we are wrapping that system with the WCF LOB Adapter, we could potentially leverage that adapter to direct messages into mockingbird). So if there is a SQL/Oracle database, because we can connect to that via WCF-SQL , WCF-Oracle etc, we can just add the mock flavors of the same otherwise we would have to mock the entire SQL/Oracle protocols which is not feasible.

For the receive side

  1. Although we can always create a test receive location with the file adapter, this is limited to ‘unit tests’. We cannot simulate other transport protocols (for example, polling sql. Also with queues (MQ/MSMQ) we would need an app that could send to the queue to activate the receive location.
  2. We could extend an adapter to use the ‘Submit Direct’SDK  sample to send messages into BizTalk directly and configure this.
  3. The context properties argument also applies here. A lot can be set artificially on the message. Similarly transactional behaviour could also be applied.

So, what about other current tools in this general area ?

  1. Some of this kind of testing can be done with BizUnit (example : sending messages to a queue or reading from a queue). BizUnit could also be extended (example : a correlation aware queue listener) but BizUnit’s focus is on distinct steps that verify behaviour rather than on causing/forcing some behaviour which we can do via the adapters. The adapter approach also keeps this testing ‘within the boundary of Biztalk’ . while BizUnit will complement this nicely from the outside.
  2. LoadGen can also help on the receive side. Again, LoadGen’s focus is on load/stress testing rather than functional behaviour. I think it may be possible to use LoadGen with Mockingbird (maybe as part of these adapters).
  3. BizMock is another tool that is in similar territory. But having discussed MockingBird with Pierre Milet Llobet, the author of BizMock, I don’t see any overlap here. BizMock is focussed on providing a fluent interface to help with a TDD approach to BizTalk testing and on providing a mock adapter that is used within that test scope, but MockingBird’s adapters will be ‘proper’ infrastructure and integration test faciliators rather than a unit test tool.

Okay, so these are my thoughts on extending MockingBird into the arena of mock BizTalk adapters and I would really like to get feedback from the BizTalk community on this. What do you think of the idea? If you have some experience with the WCF LOB Adapter SDK (which I’ve only played with briefly) perhaps there’s some suggestions you can make or tips/gotchas you can make us aware of ? Is this an area you could get involved with (not necessarily have to contribute code, there are bandwidth constraints on all of us, but potentially send us suggestions, design ideas , maybe be an early tester etc?) .

Let me know. All feedback would be greatly appreciated.

Advertisements

Written by santoshbenjamin

June 20, 2010 at 1:28 PM

2 Responses

Subscribe to comments with RSS.

  1. Glad to hear you are looking at an LOB adapter for MockingBird. I think it could take MockingBird forward a lot. I’ve two suggestions I’d like to contribute:

    1.
    You talk about a lot of features that a LOB approach could add to MockingBird, but even if an adapter was developed that had just the same functionality of MockingBird today there would be a lot of value. Ease of use would be one big benefit. You would be able to create and configure your mocked endpoints mostly within the BizTalk Administration Console. You could then import and export the bindings just as you would for your production settings. This would make continuous integration environments for testing BizTalk a lot easier to create.

    2.
    At the moment MockingBird has basically 2 ways to generate a response, static responses that are served up based on something within the request (soap action, xpath queries..) and the xsl stylesheet option. The LOB adapter would bring context properties into play. In order to take advantage of this I think that MockingBird may need a scripting option. The adapter could be configured with one of 3 options static, xsl or script. The script option would be configured with the location of a script file, probably just a c# method with a common signature. This script would be passed in the message and the context properties and would be able to create a response however it saw fit.

    Hope this is useful.

    Cormac O'Brien

    June 21, 2010 at 10:25 AM

    • Cormac,
      Great points. The script option for the response handling sounds really good. Will put that on the design list..
      cheers
      benjy

      santoshbenjamin

      June 21, 2010 at 5:35 PM


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: