Posts Tagged ‘Mocks’
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
- 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.
- Adapters will allow us to simulate transactional behaviour.
- 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:// )
- 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
- 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.
- We could extend an adapter to use the ‘Submit Direct’SDK sample to send messages into BizTalk directly and configure this.
- 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 ?
- 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.
- 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).
- 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.
MockingBird v1 is now formally released. With the squeeze in available time for personal projects, it’s taken me nearly 6 months since the beta and only recently did the site see any check-ins. There’s quite a few updates, and enhancements to the suite. Actually the beta was pretty stable with hardly any bugs that needed to be fixed but there were a few feature requests and to be honest, I started getting rather impatient to move to WCF but needed to formalize the v1 release first. Here’s a laundry list of all the features of the new release. The documentation, included with the package has also been substantially updated.
This release will be the last to support the ASP.NET HttpHandler. V2 will be completely revised to support WCF. The change in the engine should be transparent to the end user and of course with WCF we will get a lot more benefits including transport independent request interception. It will also be the last to support an independent “Studio” module as I have some plans for a brand new UI
Simulator functionality changes
· Now supports Enterprise Library logging as well as log4net
· Logging all request and response operations.
· Support for "mapped soap Actions" (when soapActions do not correspond one to one with operation names or when the default parsing of soap actions cannot be done)
· Supports mapping of operations to request element root names (when soap actions are all the same, such as in Apache Axis web services)
Simulator Packaging changes
· Config for unity and services now externalized
· MockingBird system config now externalized
Simulator Internal changes
· System Configuration Manager abstraction layer for config data storage
· StrongTyped application configuration.
· New OperationNameInferenceEngine
· Support for tokens and token expansion in configuration settings.
· Disabling of context menu on all nodes except for message level nodes.
· WSDL Browser "Save As " dialog now supports proper file masks (also takes in the service name and suggests the name for the file)
· No unhandled exceptions in the studio.
· Auto resize of all controls on form size change.
· Additional entry points to the XIG.
A big thank you to all who sent comments and gave me feedback. I hope you find the updates in this release to be useful.
V2 is going to be really big, so watch this space.
For v2, There are a number of work items published on the CodePlex space so please weigh in on them and vote for the ones that will be most useful to you and also please feel free to send me suggestions for other features as well as bug reports.