This exercise will demonstrate how to build and deploy all of the components necessary to publish messages from BizTalk RFID to an MSMQ. It will demonstrate the first half of the steps in publishing events to BizTalk Server using MSMQ.

1. Begin by creating a message queue to which an event can be published. This can be done by taking these steps:
   1. From Administrative Tools, open Computer Management and expand the Message Queuing header. If message queuing is not available, you can add it through Add Windows Components.
   2. Right-click Private Queues and create a new queue named publishtobiztalk. Ensure that the queue is transactional (as shown in Figure 8-2) and click OK.
      

      Figure 8-2. Creating a private transactional queue

2. Using BizTalk RFID Manager, create a new process by right-clicking Processes from the main window and selecting New Process.
3. In the window that opens, enter an appropriate name for the process (as shown in Figure 8-3). Set the “Tag processing mode” property to Transactional and enter a description. Make sure that the Start Bind Wizard check box is checked, and click OK.
   

   Figure 8-3. Adding a new process

4. In the Bind wizard, on the Bind Processes to Logical Devices screen, click the New button. This will allow for the creation of a new device.
   1. Give the device a valid name and select the device. Click Next.
   2. On the “Configure logical device” screen, select a device that has been set up. If no devices are available, a new device will need to be created. This exercise will use the ContosoTestDevice provided with the BizTalk RFID SDK. Once you’ve selected the device, click Next.
5. Add the MSMQ event handler on the Configure Components screen of the Bind wizard. Take the following substeps to reference this event handler (you must deploy the assembly to the GAC prior to taking these steps):
   1. Click the New Component button. This will open the Add Component dialog box.
   2. Select Public as the type of component to register, and then click the Register button. This will enable the selection of the MSMQ event handler DLL that was deployed to the GAC.
   3. In the window that opens, select MSMQEventHandler from the list and click the Register button (as shown in Figure 8-4).
      

      Figure 8-4. Registering the MSMQ event handler

   4. Once the event handler has been registered, it can be added. Click the Add button and configure the event handler properties. The MSMQ event handler has two properties: the name and the queue address. You should enter the queue address in the format .private$publishtobiztalk. The fully configured event handler is shown in Figure 8-5.
      

      Figure 8-5. Configuring the MSMQ event handler

   5. Complete and exit the Bind wizard once everything has been configured successfully.
6. Right-click the PublishToBizTalk process and select Start.
7. To test that the process has been configured properly, you can publish an event. One way to do this is to use the RFID client command-line tool. The steps to test the process using this tool are as follows:
   1. Make sure that the PublishToBizTalk process is started and the device being referenced by this process is enabled.
   2. Create an XML document that represents an event that is being submitted. This document will be sent using the command-line tool. An example of a document is shown in Figure 8-6. Save the document to an easily accessible path on the hard drive.
      

      Figure 8-6. Sample event XML

   3. Using a Visual Studio command prompt, execute the following command-line statement. This statement tells the RFID client utility to publish the event in the XML document to a specific logical device within a specified process.
      rfidclientconsole -m localhost AddEventToProcessPipeline
PublishToBizTalk rfidsample.xml MSMQDemoDevice
   4. After the event has been sent, you need to check several items:
      1. Check the event viewer for any errors. If an exception occurs during processing of the event, it will be logged to the Windows Event Viewer.
      2. Check the target MSMQ. If the event made it, the message body will be available on the queue in the message queuing section of Computer Management (in Administrative Tools).
      3. In BizTalk RFID Manager, right-click the PublishToBizTalk process and select View Tags. Events that have been submitted will be listed in the window that opens (as shown in Figure 8-7).
         

         Figure 8-7. Viewing all submitted tags in RFID Manager

This exercise will demonstrate how to subscribe to the events that are published to the MSMQ, as outlined in Exercise 8-1. The components created will consist of an MSMQ receive port and a file send port. The file send port will write out an XML file that represents exactly what was on the MSMQ.

1. Using the BizTalk Administration Console, create a new MSMQ receive port and perform the following substeps:
   1. Name the receive port ReceiveFromBizTalkRFID.
   2. Set the receive pipeline as PassThruReceive. (The document will be picked up without inspection.)
   3. Set the queue address to FORMATNAME:DIRECT=OS:LOCALHOSTPRIVATE$PUBLISHTOBIZTALK.
   4. Set the remainder of the properties as shown in Figure 8-8.
      

      Figure 8-8. Configuring the MSMQ receive port

2. Once the receive port has been successfully created, add a new file send port. This send port will subscribe to the receive port created in step 1, and will write out a file to a file directory. Perform the following substeps:
   1. Name the send port OutputRFIDEvent.
   2. Set the send pipeline to PassThruTransmit.
   3. For the file path, set the file to output to a valid location.
   4. Set a filter to subscribe directly to the receive port by entering the values shown in Figure 8-9.
      

      Figure 8-9. Setting a filter on the send port

3. Start the send port and enable the receive port. If an event has previously been published to the queue, it should be immediately picked up and written out to the specified file location. If no event is on the queue, use the steps in Exercise 8-1 to publish a new event. An example of the format of an XML document that could be written out is shown in Figure 8-10.
   

   Figure 8-10. Sample output XML

This exercise will introduce the use of the SqlServerSink event handler. Note that you must complete the steps in Exercise 8-1 prior to beginning this exercise.

1. Stop the PublishToBizTalk process in BizTalk RFID Manager if it is running. Once it has been stopped, right-click the process and select Edit.
2. Right-click Component Bindings and select Add New Component. Add the SqlServerSink event handler so that it appears in order after the MSMQ event handler, as shown in Figure 8-12. When the event handler is added, a dialog box containing the configuration settings will open. Assuming that the database is on the local machine, the default settings can be retained.

   Note The MSMQ event handler is designed to be the first component in a list. The SqlServerSink event handler can be added at any point. An event handler must be designed to listen for an event if another event handler appears before it in the component list.

   

   Figure 8-12. Adding the SqlServerSink event handler to the process

3. Once the component has been added, start the PublishToBizTalk process.
4. Test the process using the same technique as outlined at the end of Exercise 8-1. If everything has been configured correctly and no errors occur, the event should arrive on the MSMQ and in the rfidsink database. To find the event in the rfidsink database, run the following query:
   select * from tagevents

The BizTalk SQL adapter is an easy-to-configure component that can poll a database, retrieve records, and deliver them to the BizTalk MessageBox. This exercise assumes that all of the earlier exercises in this chapter have been completed successfully.

1. The ReceiveFromBizTalkRFID receive port created in Exercise 8-2 will be extended to support a SQL receive location. To do this, open the receive port in the BizTalk Administration Console and click the Receive Locations tab. Currently, there should be only one receive location in the list—the MSMQ receive location.
2. Click the New button to create a new receive location. Name this receive location SQL, set the Type property to SQL, and set the receive pipeline to PassThruReceive.
3. To configure the SQL adapter, click the Configure button next to the Type property. Set the configuration information as shown in the following substeps (see Figure 8-13 for a fully configured adapter):
   1. For the Connection String property, click the ... button and connect to the rfidsink database using the appropriate credentials (generally, Windows NT Integrated security will work). Click the Test Connection button to validate that the information is correct, and then click OK to save the settings.
   2. For the Document Root Element Name property, enter a value such as Results. This will be the root node that wraps all of the results that will be returned.
   3. Set the Document Target Namespace to any valid namespace—for example, http://PublishToBizTalk.
   4. The SQL Command property is what will call the stored procedure and get back results. Set the value to exec GetAndDeleteEventsForBizTalk 'PublishToBizTalk'. The parameter represents the name of the RFID process to return results for.
   5. Leave the URI property at the default value, which will be something like SQL://localhost/rfidsink.
      

      Figure 8-13. Configuring the SQL adapter

4. Once you’ve entered the configuration settings, save the receive location by clicking OK.
5. Enable the receive location. The steps in Exercise 8-2 worked through creating a file send port that subscribed to all data coming in on the PublishToBizTalk receive port. Since this new receive location was added to the PublishToBizTalk port, all documents will be automatically written out by the send port. When the receive location is enabled, check the output directory of the OutputRFIDEvent port. If events existed in the rfidsink database, a new file should be written. If no events existed, publish one or more test events to the rfidsink database; these should be automatically picked up and written out by BizTalk Server. The output should look similar to that shown in Figure 8-14.
   

   Figure 8-14. An example of the GetAndDeleteEventsForBizTalk standard formatting

This exercise will build upon the work completed in Exercise 8-3 by adding a call to the BizTalk BRE after the MSMQ event handler, but prior to the SqlServerSink event handler.

1. Begin by opening the Business Rule Composer. This will be used to create a policy with two rules.
2. Add a new policy and call it LogAndCheck. This will create a new policy set to version 1.0.
3. Right-click the version number and select Add New Rule. This first rule can be named Log, and will write an entry to the log file.
4. Next, you will create the IF conditional logic. Use the following substeps to complete this task:
   1. The logging should occur every time the rule is called. Therefore, in the IF conditions, a rule will be created that always returns true. The easiest way to do this is to drag the Equal vocabulary from the Vocabularies Predicates list and drop it on the IF logic. The result is shown in Figure 8-17.
      

      Figure 8-17. Adding the Equal vocabulary predicate to the log rule

   2. Set both arguments in the new condition to 1. The result will be a condition that states “If 1 is equal to 1.” This will always evaluate to true, and will cause the THEN logic to execute.
5. The THEN logic will now be created. This logic will call the LogEvent method in the RFIDRuleEngineContext library. Use the following substeps to complete this task:
   1. In the Facts Explorer, click the .NET tab. Right-click the .NET Assemblies folder and select Browse. In the window that opens, find the Microsoft.RFID.OobComponents assembly and add it.
   2. With the Microsoft.RFID.OobComponents assembly available in the .NET tab, expand the RFIDRuleEngineContext class and click the LogMessage method. Drag and drop this method in the THEN logic of the rule.
   3. The method requires two arguments. The first argument can be manually entered, and should read BRE Event Logged {0}.
   4. The second argument should be the get_CurrentTagReadEvent method. It can be dragged from the RFIDRuleEngineContext and dropped on the rule. The completed THEN logic is shown in Figure 8-18.
      

      Figure 8-18. The THEN logic to log an event

6. Create a new rule and call it Check. This rule will check whether the PONumber of the incoming event is equal to a test value, and if it is, it will remove the event from the process, which will keep it from being published to the SqlServerSink event handler and rifdsink database. Take the following sub-steps to complete this task (the full logic for this rule is shown in Figure 8-19):
   1. In the IF conditional logic, add the Equal operator from the Predicates list.
   2. Drag and drop the GetVendorSpecificData method from the RfidRuleEngineContext class onto the first argument. This will look at the content of the incoming event. The specific field that will be checked is PONumber.
   3. Enter the text PONumber for the parameter in the GetVendorSpecificData method. This field is in the document that has been used for testing all of the exercises within this chapter, and can be found in the RFIDSample.xml file.
   4. Enter the value Test123 into the second argument of the IF conditional logic. Test123 represents a value in the PONumber element that will be ignored.
   5. In the THEN logic of the Check rule, add the RemoveOutputEvent method from the RfidRuleEngineContext class. This event will remove a given event and prevent further execution of it within an RFID process.
   6. Drop the get_CurrentEvent method in the parameter of the RemoveOutputEvent method. This will cause the current event to be removed when the THEN logic executes.
      

      Figure 8-19. The logic for the Check rule

7. The policy is now complete. Save it.
8. Once the policy has been saved, right-click it and select Deploy.
9. After the policy has been deployed, right-click and select Publish. The policy will now be available to call from the RFID process.
10. Open RFID Manager. The PublishToBizTalk process will now be modified to include the call to the BRE. Stop the process, and then right-click it and select Edit.
11. Right-click Component Bindings on the Browse tab of the PublishToBizTalk process and select Add New Component.
12. Select the RuleEnginePolicyExecutor event handler from the list and add it to the process pipeline.
13. In the window that opens, the event handler will be configured to call the new policy in the BRE. Set the instance name to LogAndCheck and then follow these substeps to complete this task:
    1. Next to the Rules Configuration property, click the ... button next to Configure. This will open a new window where the call to the policy will be made.
    2. Select the LogAndCheck policy from the drop-down menu, as shown in Figure 8-20. Click OK to save the settings and return to the main Add Component screen.
       

       Figure 8-20. Referencing the policy in the RuleEnginePolicyExecutor event handler

14. The RuleEnginePolicyExecutor event handler should be placed between the existing HandlerMSMQ and SqlServerSink event handlers, as shown in Figure 8-21. Use the Move Up and Move Down buttons to reorder the events in the process pipeline.
    

    Figure 8-21. Adding LogAndCheck as the second item in the process pipeline

15. Once completed, validate the PublishToBizTalk process by clicking the Validate button in RFID Manager.
16. Once the process has been validated, start it.
17. When the process is started, it can be tested. Begin by testing using the same method outlined in Exercise 8-1. An event should be logged to the MSMQ and to the rfidsink database. The execution of the rules engine will log an entry to the PublishToBizTalk.log file.
18. Now test that the Check rule operates correctly. Open the RFIDSample.xml file in a text editor and change the value of the PONumber node to Test123. Retest using this modified file. This time, an event should be logged to the MSMQ, and the PublishToBizTalk.log file should be written to, but no event will be added to the rfidsink database.

Referencing and calling a BizTalk RFID web service proxy method within an orchestration will be outlined in this exercise. It is assumed that an orchestration already exists.

1. Begin by creating an orchestration variable that is of the ProcessManagerProxy type. This will allow the methods on the class to be called from an orchestration shape. Take the following actions to do this:
   1. On the Orchestration View tab of the orchestration, right-click the Variables folder and create a new variable named processManager.
   2. For the Type property of this variable, select the .NET Class option and browse to the Microsoft. SensorServices.Rfid.Management.ProcessManagerProxy assembly, as shown in Figure 8-23.
      

      Figure 8-23. Selecting the ProcessManagerProxy assembly as a variable type

2. Once the variable has been created, it can be used in an expression shape. Drop an expression shape into the orchestration and type in the variable name, processManager. All of the public methods will be available to call, as shown in Figure 8-24.
   

   Figure 8-24. Calling a proxy method within an expression shape