The MSMQ service endpoint is configured using the netMsmqBinding
with the path to the private queue as the service address. As we are
hosting our service within IIS 7.0, we do not need a separate MEX
endpoint for MSMQ, but rather, can simply apply a standard HTTP metadata
behavior to our service.
The final part of this service is the deployment. After building the service, we should confirm that the Net.Msmq Listener Adapter Windows service is running, as this is what the Windows Process Activation Service(WAS) in IIS 7.0 uses to read from our queue.
Lastly, we need to specifically enable the MSMQ protocol for our web application. This is accomplished by visiting the Advanced Settings of our application in IIS and ensuring that our Enabled Protocols contains both http and net.msmq. We can validate that our configuration is successful by visiting our service URL and seeing our service page displayed.
Let's get started
building the BizTalk pieces of our application. We start with a new
event-style schema representing an adverse event that is considered
"resolved" by the primary safety system. The schema contains a few key
nodes, which explain the resolution information that the subscriber need
to update their system.
In order to get the artifacts necessary for BizTalk to consume this service, we should choose to Add Generated Items to our project and then choose to Consume WCF Service.
Here we point to the WSDL endpoint associated with our service and end
up with the schemas and binding files we sought. We need to map our
resolved adverse event from the format received by our service to the
structure expected by our destination service.
