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 [email protected] / [email protected]

@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   Context properties  No port/adapter latency Cons:  Requires developer resources  One-Way and Solicit-Response 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   No port/adapter latency Cons:  Requires custom development  Context properties 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   As close to actual configuration (of a webservice) as you can get Cons:  One port independent of no of operations 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 additional components outside BizTalk Cons:  No latency to service calls 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-wcf custom-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   Promotes a contract first approach Cons:  A commercial tool – support 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 request and responses generation Cons:  Easy enough?

 WSDL based Mock service simulator config generation Support?