This project is read-only.

Deploying your mock service endpoints

Setup the data Files

Setting up the data files for a custom service is a slightly detailed process and in later versions (beta onwards) an application will be provided to make this faster and easier but right now it is a manual process.

The following picture shows the layout of the data files
  1. Setup the ‘config’ file for the endpoint(s)
    1. The configuration file tells the handler what the incoming operations are and what the responses need to be (the structure of the config file is described in the next section). There is one file for every end-point, for example, Customer.asmx. (In this example, the file would be named customer.config)
    2. The config file goes into the endpoints\{endpointname}\config folder. For example, endpoints\customer\config (Only rename the {endpointname} folder, not the others. The folder name does NOT contain the extension (e.g .asmx)
    3. To setup a config file, you can generate an instance from the supplied XSD or, better still, copy the provided example configuration and edit accordingly.
  2. Setup sample responses
    1. Responses go in the endpoints\endpointname\responses folder. (No renaming needed here). The response files here correspond to the response names set in the configuration file above. You can generate these from your web service XSD’s. (Studio will most probably provide a tool to generate instances)
  3. Setup Schemas and WSDL
    1. In the current version of the product, there is no explicit runtime need for the WSDL and the schema. In ‘normal’ development we assume that the WSDL file has been used to create the proxy and MB is only being used after that. However it may be the case that you need to put the WSDL here first and then go about proxy generation.
    2. If you do want to use the WSDLs here, then put your WSDL for the web-service in the endpoints\endpointname\wsdl folder and the schemas for the service in the endpoints\endpointname\schemas folder.
    3. If the WSDL has all XSDs embedded, then there’s no further work. However if it makes use of import/include statements (with the XSDs stored elsewhere), then you need to edit the WSDL to pick up from the new XSD location. Be careful with this approach though as the BizTalk/.NET engine can choke on relative paths for XSDs when parsing a WSDL.

Setting up the Endpoint Configuration File

The following screenshot shows a sample HandlerConfiguration for the OOB Handler and a short note about the contents. (This particular screenshot shows the config file for the unit tests)
The sample configuration provided (with the source code) has detailed comments included and the Architecture & Implementation section explains this in more detail. You can also look at the config file for the “sample” endpoint that is used by the Driver application to test the installation to see how this works.


The following are the key elements
  • Control Settings: Indicates how the system matches up the operation names in the file to the incoming request. SoapAction means that the system looks for an operation name here that matches against the incoming soap action.
  • Operations: There is one Operation corresponding to every Operation/Webmethod in the endpoint/WSDL.
  • ResponseStrategy: The ResponseStrategy tells the system how you want it to locate responses. None – indicates a One Way message, Default –indicates that there is only one response file available and XPath means that there are many possible responses and the right one is selected through applying an XPath expression on the body of the incoming request.
  • ResponseBehavior: ResponseBehavior applies to each response and here you tell the system whether to behave normally or to throw an error (which in turn may be a SoapFault or a Timeout)

Last edited Jan 13, 2009 at 12:37 PM by santoshbenjamin, version 2


No comments yet.