Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>This goes to the heart of one of my main irritations as a BizTalk developer - BizTalk does not lend it self to unit testing. From the fact the 99% of your interfaces into BizTalk applications are message based and have a huge number of possible inputs, through to the opaque nature of orchestrations, BizTalk offers no real way of testing units of functionality as... well... units.</p> <p>For BizTalk, integration tests are sadly often the only game in town.</p> <p>That results in, due to no fault on the part of Kevin Smith, BizUnit being (IMO) a misnomer. A better name would perhaps be BizIntegrationIt. BizUnit offers a range of tools that assist in integration testing, the majority of its tests, like checking if a file has been written to a given directory or sending an HTTPRequest to a BizTalk HTTPReceive location are all strictly speaking, testing integration.</p> <p>Now that I've gotten that rant out, what you are asking for is something I've been thinking about for a long time, the ability to create automated unit tests that give some real confidence that my making a small change to a map won't suddenly break something else downstream, as well as a way to remove dependance on external services. </p> <p>I've never thought of any nice way of doing this but below is a solution that <strong>should</strong> work, I've done variations of each part of this in isolation but never tried to but them all together in this specific form. </p> <p>So given the desire to mock a call to some external service (that may not even exist yet) without needing to actually make any external call <strong>and</strong> wanting to have the ability to set expectations for that service call and to specify the nature of the response, the only method I can think of is to develop a custom adapter.</p> <h2>Mock webservice using custom adapter</h2> <p>If you build a custom request-response adapter you can plug it into your send port in place of the SOAP adapter. You can then specify properties for the adapter that allow it to behave as a mock of your webservice. The adapter would be similar in concept to a loopback adapter but would allow internal mocking logic.</p> <p>Things that you might want to include as adapter properties:</p> <ul> <li>Expected document (perhaps a disk location that specifies an example of what you expect your BizTalk applicaiton to send to the webservice).</li> <li>Response document - the document that the adapter will send back to the messaging engine.</li> <li>Specific expectations for the test such as lookup values in document elements.</li> </ul> <p>You could also have the custom adapter write to disk and setup a BizUnit step to validate the file that was written out.</p> <p>Building a custom adapter is non-trivial, but possible, you can get a good start from the <a href="http://www.codeplex.com/BizTalkAdapterWizard" rel="nofollow noreferrer">BizTalk Adapter Wizard</a> and there is an article on deploying custom adapters <a href="http://msdn.microsoft.com/en-us/library/aa561871.aspx" rel="nofollow noreferrer">here</a>.</p> <p>There is a bug in the code generated by the wizard, you will need to change <code>new Guid(""),</code> to <code>new Guid()</code>.</p> <p>There are also some examples of building custom adapters in the BizTalk SDK.</p> <p>Another option is to use a plain http page and the HTTP solicit response as discussed <a href="http://geekswithblogs.net/gwiele/archive/2004/11/10/14737.aspx" rel="nofollow noreferrer">here</a>, all your logic goes in the http page. This is probably simpler if you are happy having an http call, and setting up an IIS port to listen for your test.</p> <h2>Initialising unit tests</h2> <p>You can import binding files into a BizTalk application using a .bat file. </p> <p>If you make a new binding file for each test you run, as well as for your standard applicaiton set up, you can then run the appropriate batch file to apply the right binding.</p> <p>Each binding file would change your webservice sendport to use the mock custom adapter and set the specific properties for that test.</p> <p>You could then even make a custom BizUnit step that (perhaps) generated binding settings based on settings in the test step and then ran the shell commands to update the bindings.</p> <h2>Testing Message Contents</h2> <p>A final thing that you might want to consider, to really tie all this together, is some way of testing the contents of messages. You could do this in your mock adapter, but that would get tedious very quickly for large messages, or for a large range of possible input messages.</p> <p>One option is to make a custom pipeline that calls <a href="http://www.schematron.com/" rel="nofollow noreferrer">Schematron</a> to validate files that it receives. Schematron is a schema language that allows a much richer level of file inspection that xsd, so you can check things like "If element x contains this content, I expect element y to be present".</p> <p>If you built a custom pipeline that took a schematron schema as a parameter, you could then swap in a testing file for a specific unit test, validating that for this test, when you call the webservice you get a file that actually matches what you want (and doesn't just match the xsd)</p>
    singulars
    1. This table or related slice is empty.
    1. POMocking WebService consumed by a Biztalk Request-Response port
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USDavid Hall
    1. USDavid Hall
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POMocking WebService consumed by a Biztalk Request-Response port
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload