• 18:00 - ”BizTalk Tips och Trix”
Mikael Sand
• 19:00 - Paus, mingel, diskussioner
• 19:30 - ”Kanoniska datamodeller”
Johan Tuvstedt
• 20:00 – ”Lösningar för att mocka en port”
Johan Hedberg
3:e oktober
“Effektiv systemdokumentation i ett integrationsprojekt”
Richard Hallgren
“BizTalk IaaS, PaaS – Hybridbaserade Integrationslösningar med BizTalk lokalt
och/eller i molnet”
Michael Olsson
Johan Hedberg, Enfo Zystems
http://blogical.se/blogs/johan
johan@jeh.se / johan.hedberg@enfo.se
@JoHed






Raise awareness of options
Present different solutions to mock a send port
Consider how they differentiate
Discuss Pros and Cons
Talk about how they accomplish the work
Look at (some) code and implementation logic
Photo by moyogo @flickr

Introduction
 What is mocking?
 Why Mock a Send Port?

Solutions
Photo by Dan Holtmeyer @flickr

In this context...

”Mocking is the simulation of an system or service that mimics
the behavior of the target system or service”





PoC
Test
Isolation
Parallell development
Cost savings



Treating mock as the real thing
Plan for the development and maintenance
Don’t overdo it, KISS






Core adapters
Null adapter
Orchestration
Web Page/Service
Custom Adapters and Bindings
Frameworks and Tools

Replacing the ports adapter with the FILE/MSMQ/MQ/etc.
adapter

Pros:
 Easy
 Close copy to actual port configuration
 Allows access to output

Cons:
 One-Way
 Limited flexibility
 WCF Behaviors etc

Replacing the ports adapter with the NULL adapter

Pros:
 Easy-ish
 Close copy to actual port configuration

Cons:





One-Way
No access to output
Limited flexibility
WCF Behaviors etc
Requires adapter development/install

Replacing the ports pipeline with a consuming pipeline

Pros:
 Easy-ish

Cons:






One-Way
Greater config differences
No access to output
Limited flexibility
WCF Behaviors etc
Requires pipeline and pipeline component development/install

Creating one orchestration per send port oprtation to simulate response

Pros:






Easy
Flexible
One-Way and Solicit-Response
Context properties
No port/adapter latency
Cons:




Requires developer resources
One orchestration per send port could result in many additional orchestrations
Limited to MsgBox measurements
Far away from the actual configuration

Creating a generic orchestration that can handle all send ports
 Based on a convoy pattern and configuration (?)

Pros:





Flexible
One-Way and Solicit-Response
Context properties
No port/adapter latency
Cons:





Requires custom development
Limited to MsgBox measurements
Configuration/rule heavy
Needs to be built to your (pre-determined and generic) subscription filters
Far away from the actual configuration

Creating a HTTP page hosted in IIS called by a HTTP send port

Pros:
 Easy
 One-Way and Solicit-Response
 Possible access to output if coded

Cons:
 Limited flexibility
 IIS Install/Deployment
 WCF Behaviors etc

Creating a WCF Service called by a WCF send port

Pros:






Flexible
One-Way and Solicit-Response
WCF Behaviors
One port independent of no of operations
As close to actual configuration (of a webservice) as you can get
Cons:
 Install/Deploy
 Context properties

Creating an adapter using the Adapter Framework to
act as the mock message factory

Pros:





Flexible
Can control context properties
No latency to service calls
No additional components outside BizTalk
Cons:
 Big difference from WCF configuration
 Custom Adapter development

Adding a custom channel to the channelstack to
act as the mock message factory
 Paolo Salvatori has a sample of this technique at
http://blogs.msdn.com/b/paolos/archive/2011/04/05/how-to-use-a-wcfcustom-channel-to-implement-client-side-caching.aspx

Pros:
 Close to actual configuration
 No latency to service calls
 No additional deployment outside BizTalk

Cons:
 Non-trivial development of channel and behavior

Creating a custom LOB Adapter SDK Adapter to
act as the mock message factory
 There is a tutorial showing how to develop an LOB EchoAdapter that
takes you step by step through this technique at
http://msdn.microsoft.com/en-us/library/bb798134(v=bts.10)

Pros:
 Close to actual configuration
 No latency to service calls
 No additional deployment outside BizTalk

Cons:
 Custom Adapter/Binding Development

SoapUI is a popular tool to test webservices that
can also create mock services

Pros:
 If you are confomfortable using SoapUI
 A commercial tool – support
 Promotes a contract first approach

Cons:
 If you are not comfortable using SoapUI
 A commercial tool – cost
 Need to re-generate service on contract changes

BizMock is a framework for testing Orchestrations, Schemas,
Maps and Pipelines by writing Visual Studio c# unit tests
 Available at http://bizmock.codeplex.com/

Pros:
 Allows unit tests of orchestrations

Not really in focus for this discussion

Is a collection of pipeline components that trigger boo scripts
that can perform work like promoting context properties.

Pros:
 Cool sample of very Dynamic pipeline components
 Allows context property promotion

Cons:
 Not really mocking in itself
 boo language

Uses a service simulator (HTTP Handler or WCF interceptor) to return a
response
 Available at http://mockingbird.codeplex.com/

Pros:






Easy enough
No development effort
No cost of purchase
WSDL based Mock service simulator config generation
WSDL based Mock request and responses generation
Cons:
 Easy enough?
 Support?