Chapter 8 detailed how to communicate with BizTalk RFID by using BizTalk Server as the integration broker. Often, it is unnecessary to have orchestrations and ports sitting between BizTalk RFID and external applications, and the purpose of this chapter is to illustrate how to effectively implement more direct patterns of communication. This chapter uses two primary discussions to illustrate how to interact directly with BizTalk RFID throughout the enterprise. The first discussion centers on SQL Server Reporting Services, and making the BizTalk RFID SQL data accessible to external platforms and applications. The second discussion centers around calling BizTalk RFID from a SharePoint 2007 web part. By reading these discussions and working through the exercises, you will come to understand how to interact with BizTalk RFID across networks and platforms, and you should be able to apply this understanding to whatever distributed application model is needed.
Key ideas that will be introduced are the following:
- Querying BizTalk RFID databases and making the information available in SQL Server Reporting Services
- Building basic reports in Reporting Services
- Calling BizTalk RFID from machines across different network configurations
- Interacting with BizTalk RFID from a SharePoint 2007 web part
- Deciding when to use a custom web service vs. the BizTalk RFID web service proxy assemblies
Integrating with SQL Server Reporting Services
The purpose of this section is to outline how data within BizTalk RFID’s databases can be made available to end users with SQL Server Reporting Services. There are a wide variety of metrics and data that would be useful to display in web-based reports and dashboards. This section will illustrate a subset of these by concentrating on devices and related TagRead events held in two databases: RFIDSTORE and rfidsink. The discussion will center on how to extract relevant data from these two databases and display it in web-based reports. The key ideas that will be introduced are as follows:
- Creating several stored procedures to query devices and related tag events
- Creating several Reporting Services reports that call the stored procedures and display the returned data
The architecture of this section is shown in Figure 9-1. It shows the databases, the two stored procedures, and the Reporting Services reports, which are rendered as ASPX pages.
Figure 9-1. SQL Server report architecture
Querying the BizTalk RFID Databases
The databases that lie beneath BizTalk RFID are relatively simple. Much of the information that defines devices and events is stored in XML strings within ntext fields. There are a number of preexisting stored procedures that provide certain data. In many cases, however, custom queries will need to be written to access the desired information. The discussions in this section will outline how to access information in the XML and how to create certain metrics across multiple databases.
Querying Devices and Related Events
The first stored procedure that will be outlined (shown in Listing 9-1) concerns retrieving all tag events related to devices. This procedure will demonstrate how to work with the device information stored in XML and retrieve data from both databases. It includes a single input parameter, vchDeviceStatus, which will determine what devices to return based on their connection status. You begin the procedure by placing all of the device information into a temporary table, converting the runtimeDeviceInfo field from ntext to XML in the process. This allows for easy access to the connection status information in the next portion of the procedure, which returns the information from the two tables.
Note The stored procedure shown in Listing 9-1 would be deployed on a custom database used primarily for reports in Reporting Services. It is not intended to be placed on any of the preexisting BizTalk RFID databases.
Listing 9-1. The Report Devices and Events Stored Procedure
-- =============================================
-- Sample Implementation:
-- EXEC spReportDevicesAndEvents 'ConnectionEstablished'
-- =============================================
CREATE PROCEDURE [dbo].[spReportDevicesAndEvents]
(
@vchDeviceStatus varchar(50) = 'All'
)
AS
BEGIN
-- loading into a temporary table allows for easy conversion
-- from ntext to XML
SELECT name, CAST(runtimeDeviceInfo as XML) As runtimeDeviceInfo
INTO #temporary
FROM RFIDSTORE.dbo.devices
-- join the two databases together to get information
SELECT d.name, t.sinktime
FROM #temporary d
LEFT JOIN rfidsink.dbo.TagEvents t ON t.DeviceName
COLLATE DATABASE_DEFAULT = d.name COLLATE DATABASE_DEFAULT
WHERE (@vchDeviceStatus = 'All' OR
CAST(d.runtimeDeviceInfo.query(
'declare namespace
s="http://schemas.datacontract.org/2004/07/MS.Internal.Rfid.Service.Devices";
data(//s:m_connectionStatus)') As varchar(50)) = @vchDeviceStatus
)
END
There are two important items to point out in this query: collation and the XML query. First, the RFIDSTORE and the rfidsink databases are, by default, created with different collation. Trying to join one table to another in a query will result in the error that states the following:
Cannot resolve the collation conflict between "SQL_Latin1_General_CP437_BIN"
and "SQL_Latin1_General_CP1_CI_AS" in the equal to operation.
Adding the COLLATE DATABASE DEFAULT directive will force both tables to temporarily adhere to the default collation of SQL Server, and will allow the query to execute without error.
Second, querying the XML to get the connection status can be a little challenging. As stated before, the runtimeDeviceInfo field is an XML string stored in an ntext field. Once the field is converted to an XML data type, the node that contains the connection status can be queried using XQuery. However, an extra level of complexity is added due to the namespace stored in the root element of the document (see Figure 9-2). This namespace must be declared in the XQuery statement to successfully retrieve the value of the connection status node; without the namespace declaration, no value will be returned.
Figure 9-2. Example of the runtimeDeviceInfo XML
Querying Count Events by Device
The second stored procedure is very simple. There is nothing that needs to be pointed out about the procedure, beyond the code listing shown in Listing 9-2. The purpose of including this procedure in the discussion is to illustrate how a chart can be used in Reporting Services to display BizTalk RFID metrics in a visually appealing way.
Listing 9-2. spCountEventsByDevice
-- =============================================
-- Sample Implementation:
-- EXEC spCountEventsByDevice
-- =============================================
CREATE PROCEDURE [dbo].[spCountEventsByDevice]
AS
BEGIN
SELECT DISTINCT DeviceName
,(SELECT COUNT(*)
FROM rfidsink.dbo.TagEvents child
WHERE child.DeviceName = parent.DeviceName) As EventCount
FROM rfidsink.dbo.TagEvents parent
END
Writing the SQL Server Reporting Services Reports
With the stored procedures defined, the accompanying web reports can now be created in Reporting Services. This section will walk through how to build a report for each of the procedures outlined in the previous section. Before looking at creating the reports, Exercise 9-1 will introduce you to creating a Reporting Services project, in case you’re unfamiliar. After the project has been created, you will add two individual reports to it.
Exercise 9-1. Creating a SQL Server Reporting Services Project
This exercise will outline the steps necessary to create a Reporting Services project.
- Open SQL Server Business Intelligence Development Studio. This can be found at Start
All Programs
- Create a new Report Server project, available under the Business Intelligence Projects heading (as shown in Figure 9-3).
Figure 9-3. New Report Server project
- Once the project has been named and created, the next task is to create a data source. Right-click the Shared Data Sources folder in the Solution Explorer window and select Add New Data Source. Connect to the database where the RFIDSTORE and rfidsink databases reside (this assumes that both databases are on the same SQL server).
Creating the Report for Devices and Related Events
The first report interacts with the stored procedure defined in Listing 9-1. It will allow a user to determine what devices to query (those that are connected, disconnected, or both) through the use of a drop-down box, and will display a report similar to that shown in Figure 9-4. To show you how to get to this result, Exercise 9-2 will walk through connecting a new dynamic report with the stored procedure.
Figure 9-4. The Dynamic Devices and Events report with the user-controlled drop-down
Exercise 9-2. Building the Dynamic Devices and Events Report
This exercise will walk through the creation of a new SQL Server report that is tied to the stored procedure outlined in Listing 9-1. It assumes a project has already been created (see Exercise 9-1).
- Add a new report to the SQL Server Reporting Services project. The Report wizard will open.
- Begin by connecting to the appropriate data source in the Report wizard and move on to the Query Builder screen.
- The Report wizard requires that a SQL statement be entered in the Query Builder. Generally, with stored procedures, this fails. In the case of the
spReportDevicesAndEventsstored procedure, it will fail because there is a temporary table included in the stored procedure. The Query Builder has a problem generating the result set and throws an error. To get around this, take the following substeps:
- Click the Query Builder button.
- Enter Select ‘a’ as temp, ‘b’ as temp2 into the Query Builder window. Any generic SQL statement will work, with the goal being to allow the report to be created. The reason this specific statement is helpful is that it will set up the report with two columns, which is what the result set that is returned by the stored procedure contains.
- Click OK, and then move on to the Report Type screen.
- Set the Report Type to Tabular and go to the next screen.
- Click the Finish button (you don’t need to add the temp field to the Displayed fields—just ignore and move on).
- On the final screen, give the report an appropriate name and exit the Report wizard.
- The initial version of the report will appear, looking somewhat similar to that shown in Figure 9-5.
Figure 9-5. Temporary report (before the query has been corrected)
- The first task is to get the appropriate result set (instead of the temporary result added in step 3). You do this by clicking the Data tab and taking the following substeps:
- Set the Command Type drop-down to Stored Procedure.
- Enter the name of the stored procedure in the query window: spReportDevicesAndEvents.
- Click the exclamation mark (!) to run the query. A small window should pop up that requests the value of the stored procedure parameter (see Figure 9-6). You can set this to All.
Figure 9-6. Entering the value for the device status parameter
- Click OK to run the query. A list of results will be returned (assuming there are values in the databases—if not, post some events).
- With the stored procedure returning valid results, update the report’s dataset. You can do this by clicking the Data tab, right-clicking the Report Datasets heading, and selecting Refresh. The refreshed dataset should look like that shown in Figure 9-7.
Figure 9-7. The corrected dataset with parameters returned from the query
- Next, update the report grid by clicking the Layout tab. Drag the “name” field from the dataset and drop it in the first column. Drag the “sinktime” field and drop it into the second column.
- Rename both of the column headers to an appropriate value and resize the report grid so that the data has plenty of room to display (see Figure 9-8).
- With the data structured properly, the final tasks involve enabling a dynamic parameter to be passed in. Click the Report menu option and select Report Parameters. This opens a window where the device status parameter used by the stored procedure can be worked with.
- In the “Available values” window, enter three nonqueried values, as shown in Figure 9-9. The values correspond to the three values that are stored in the XML string in the RFIDSTORE database’s device table, and that are queried in the stored procedure. The labels are simply what appear to the end user in the drop-down. In addition to these values, set the Non-queried default value to All. Once all of these are entered, click OK to continue.
Figure 9-9. Setting values for the vchDeviceStatus parameter
- The report is complete, and should look like that shown previously in Figure 9-4. You can validate this by clicking the Preview tab.
Note The report is complete within the Visual Studio project, and it can now be deployed. Once a report has been deployed, it is moved to a virtual directory in IIS, and can be referenced via a URL and embedded into a standard ASPX page.
Creating the Count Events by Device Report
The goal of the Count Events by Device report is to show how to create a chart report that is tied to BizTalk RFID metrics. The steps to creating a chart are slightly different than they are with a standard report, and therefore need some additional explanation. It is also important to highlight that some information from BizTalk RFID is of greater value in a well-structured, visually appealing chart than it would be in a text-based presentation. The chart that will be created in Exercise 9-3 is shown in Figure 9-10.
Figure 9-10. The Count Events by Device pie chart
Exercise 9-3. Building the Count Events by Device Pie Chart
This exercise will walk through the creation of a new SQL Server report that is tied to the stored procedure outlined in Listing 9-2. It assumes a project has already been created (see Exercise 9-1).
- Create a new report and add the appropriate data source.
- The dataset should be the results returned by the
spCountEventsByDevicestored procedure. Use the detailed steps in Exercise 9-2 to complete this step.- Set the initial state of the report to Tabular. Once the report is in designer mode, the table should be deleted to make room for the chart.
- On the Toolbox tab, select the chart, drag it, and drop it onto the design surface. It will default to a bar graph.
- Right-click the bar graph and select Chart Type. Set the type to an exploded pie chart.
- Drop the EventCount field from the dataset onto the “Drop data fields here” section, and drop the DeviceName field onto the “Drop series fields here,” as shown in Figure 9-11.
- Next, set the properties of the chart by right-clicking and selecting Properties. The following substeps will be helpful in creating the chart:
- To get the number of events to show on top of the pie sections, click the Data tab. Click the Edit button to the right of the Values box and select the Appearance tab. Selecting the “Show markers” check box will enable this to happen (see Figure 9-12).
Figure 9-12. Enabling the markers prints the count on the pie slice.
- To give the device names plenty of room to display, click the Legend tab and set the properties so that the legend displays at the bottom center (see Figure 9-13).
Figure 9-13. Setting the placement of the legend
- The report, once completed, should look similar to that shown in Figure 9-10. You can verify this by clicking the Preview tab.
Connecting to BizTalk RFID via Remote Machines
The discussion will now turn to an important digression: introducing how to connect from a remote machine to the BizTalk RFID server. There are a variety of methods of interaction with BizTalk RFID, the most common of which is through the use of the proxy web service assemblies. These assemblies can be referenced on any machine, regardless of where BizTalk RFID is hosted. To be able to connect to the RFID server, the user under which the code is executing must be a member of the RFID_USER group on the host machine. If a user without permissions tries to connect to BizTalk RFID, an error stating “The server has rejected the credentials” will be returned to the application, and an error similar to that shown in Figure 9-14 will be logged to the Windows Event Viewer on the host machine.
Figure 9-14. An error indicating that the calling user is not a member of the RFID_USER group
Note The default port that the BizTalk RFID web services operate under is 7891.
The solution to this issue is fairly simple when connecting to a host machine that is in the same domain (or a trusted domain) of the calling machine. All that must be done is to add the user to the RFID_USER group. There should be no issues in adding the user, as the user will be accessible to be added either via the local computer groups or Active Directory (see Figure 9-15).
Figure 9-15. The RFID_USER group
For incidents where NTLM (NT LAN Manager) authentication needs to occur across machines on different domains, the easiest approach is to use the “Manage your Network Password” options on the user account that the process is running under. On Windows XP, you can do this by opening Control Panel and clicking User Accounts. A number of options are available for each user, one of which is to manage the network password. Set the password information for the domain/machine as appropriate.
However, if you’re trying to connect from a machine that is not on the network, these approaches won’t be an option. In some cases, impersonation could be used, but even that has limitations (such as over the Web). In cases where a distributed communication model is necessary and credentials can’t be standardized (such as across the Internet), it would be most appropriate to create a web service that brokers the communications between the BizTalk RFID host and the calling machines. Calling machines will be able to call the web service, and the only user that will need to be added to the RFID_USER group is the user under which the web service executes (e.g., ASP.NET).
The BizTalk proxy web services are extremely helpful, but are not appropriate for all situations. The next section covers connecting to BizTalk RFID using SharePoint 2007. It will illustrate how to connect using the web proxies, and, separately, how to use a web service to broker the calls. Once you understand both approaches, you will be able to determine when and how to use them in your own implementations.
Note The BizTalk RFID proxy web service classes should only be used by applications that are on the same network as the BizTalk RFID service. Applications outside of the network should depend on a custom web service to expose the needed methods.
Integrating with SharePoint 2007
This section will give an overview of several paths to integrating BizTalk RFID–related information with SharePoint 2007. Administration of BizTalk RFID is generally done through the RFID Manager, which is fine for development, but is limiting in a production environment. Frequently, users who should not have access to the production BizTalk RFID server (where the RFID Manager and other client tools are installed) need the ability to view data and perform administrative tasks. There are several ways to solve this, but the most appropriate is to implement an enterprise-wide solution, which would allow controlled access within a known environment. SharePoint 2007 is being widely adopted and implemented as the enterprise portal of choice, enabling extensive permission handling, interoperability with existing applications and code bases, and rapid web-based application development and deployment, and therefore will be the focus of this section.
The exercises in this section are intended to aid you in understanding how BizTalk RFID can be made available to the wider organization. The text will look at how to interact with BizTalk RFID through a SharePoint web part. The rendered web part is very simple, displaying a drop-down list of available devices, but you should be able to extend the ideas behind this to enable any type of administration needed in a web part. Anything that can be handled through the BizTalk RFID web proxy classes can be made available to users in external applications.
As outlined in the earlier discussion about connecting to BizTalk RFID from remote machines, there are two possible approaches to take. The first is to connect directly to BizTalk RFID using the web service proxy assemblies. The second is to use an intermediary web service to enable the call. The BizTalk RFID web service proxy assemblies are useful when the calling system is on the same network as BizTalk RFID. These assemblies can be added to a project and called with little effort. The architecture and components related to this approach are illustrated in Figure 9-16, and will be implemented later in Exercise 9-5.
Figure 9-16. SharePoint component architecture using BizTalk RFID proxy assemblies
In many cases, the calling application will not be on the same network as the BizTalk RFID service, or will not have permissions to interact directly with BizTalk RFID using the proxy assemblies. In cases such as this, it is more appropriate to use a custom web service to broker external requests (calling parties not on the network) from the internal systems (BizTalk RFID). The web service would reference the proxy assemblies and call the methods, exposing public web methods to the external clients. All permissions are handled by IIS, and a decoupled, easily maintainable solution is created. The architecture and components related to this approach are illustrated in Figure 9-17, and will be implemented later in Exercise 9-6.
Figure 9-17. SharePoint component architecture using a custom web service
Developing the SharePoint Web Part Foundation
Before moving on to the details of how to implement the different approaches to calling BizTalk RFID, it will be useful to first put together the foundation by building the SharePoint web part. If you’re unfamiliar with SharePoint web part development, you’ll benefit greatly by looking at the steps needed to add a custom web part to a SharePoint site. Once the foundation of the web part has been laid out, it will be extended first to call the BizTalk RFID web service proxy assemblies directly, and second to call an intermediary web service.
Exercise 9-4 details the steps needed to create and deploy a web part to SharePoint 2007. This will form the base for the remaining SharePoint-related exercises in the section. The full code for the web part framework is shown in Listing 9-3. This code sets up a single configurable field to define the BizTalk RFID host IP, and creates all of the necessary methods to render data to the user interface.
Listing 9-3. SharePoint BizTalk RFID Administration Web Part
using System;
using System.Collections.Generic;
using System.Text;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using Microsoft.SharePoint.WebPartPages;
namespace SharePointBizTalkRFIDWebParts
{
public class AdministrativeFunctions :
Microsoft.SharePoint.WebPartPages.WebPart
{
// default value of the variable. Overridden by configurable field.
private String rfidProxyHost = "192.168.0.175";
// user-configurable field declaration
[WebBrowsable(true), Personalizable(PersonalizationScope.Shared),
WebDisplayName("RFID Proxy Host Server"),
SPWebCategoryName("Administrative Function Settings")]
public String RFIDProxyHost
{
get { return rfidProxyHost; }
set { rfidProxyHost = value; }
}
protected override void CreateChildControls()
{
base.CreateChildControls();
// label to give name
Label tableDescription = new Label();
tableDescription.Text = "Devices Available: ";
// add label to control for rendering
this.Controls.Add(tableDescription);
}
protected override void RenderWebPart(HtmlTextWriter output)
{
base.RenderWebPart(output);
}
}
}
Exercise 9-4. Building and Deploying a Web Part
This exercise will demonstrate how to create a SharePoint 2007 web part that will be able to call BizTalk RFID and perform several administrative functions. The steps introduce the full development life cycle of a web part, from the build through deployment.
- Create a new C# class library project in Visual Studio. This will be the framework of the web part. Give it an appropriate name (this exercise will refer to it as AdminstrativeFunctions).
- Add the web part code shown in Listing 9-3. This includes the class declaration and web part inheritance, and a single configurable field for the BizTalk RFID host URL (used when connecting through the proxy or through a web service).
- Add an entry in the SharePoint
Web.configfile under the<SafeControls>node. The entry should look similar to the following:- Copy the
SharePointBizTalkRFIDWebParts.dllassembly to the following directory:$InetpubwwwrootwssVirtualDirectories80in- Now the web part can be added to the SharePoint gallery. Open SharePoint Server in a web browser, click the Home tab, and take the following substeps:
- Click Site Action
- Under Galleries, click Web Parts. A list of all available web parts will be shown.
- Click the New button. In the window that opens, find the entry for SharePointBizTalkWebParts and set the check box next to it. Once checked, click the Populate Gallery button.
- Validate that the web part appears, as shown in Figure 9-18.
Figure 9-18. The web part has been added to the gallery.
- Determine what SharePoint site to add the web part to. To create a site, take the following substeps:
- From the Home tab, click Site Actions and select Create Site.
- Set the title and description of the site, and give a valid URL. An example of this is shown in Figure 9-19.
Figure 9-19. Creating the site
- The remainder of the properties relate to the look and feel of the site and where it sits in relation to other SharePoint entities. Once you have entered the values, click the Create button.
- Next, add the web part to the site. Click a site and take the following steps:
- Click Site Actions
- Click the Add Web Part button in the editable area.
- Under the Miscellaneous heading, the AdministrativeFunctions web part will be available. Click the check box next to it, and then click the Add button. The outcome should look similar to that shown in Figure 9-20.
Figure 9-20. Adding the web part to a site
- Once the web part has been added, click the Exit Edit Mode link to return to the site’s root.
- With the web part deployed, you can modify the value of the configurable field (the IP—or namespace—of the BizTalk RFID host) by clicking the drop-down arrow on the right-hand side of the web part and selecting Modify Shared Web Part. The modification of the configurable field occurs in the properties of the web part, as shown in Figure 9-21.
Figure 9-21. Modifying the configurable host value
- The creation and deployment of the web part is complete. You can make updates to the web part and redeploy the assembly by copying to the same
bindirectory as before ($Inetpubwwwrootwss VirtualDirectories80in) and refreshing the web page.
Extending the Web Part to Use the RFID Web Service Proxies
Now that the web part has been defined, it can be extended to call BizTalk RFID using the web service proxy assemblies. These assemblies can be added to the Visual Studio project and the methods can be called directly from the web part. The assemblies that need to be added are shown in Exercise 9-5. The code shown in Listing 9-4 contains a method that can be added to the web part code to return a list of devices that are available from BizTalk RFID.
Listing 9-4. The GetDevices Method
// returns a list of device names in a sorted ArrayList
public ArrayList GetDevices()
{
ArrayList results = new ArrayList();
DeviceManagerProxy proxy = new DeviceManagerProxy(rfidProxyHost);
DeviceDefinition[] devices = proxy.GetAllDevices();
for(int x=0; x<devices.Length; x++)
{
results.Add(devices[x].Name);
}
results.Sort();
return results;
}
The GetDevices method can be called from CreateChildControls in the web part, and the results can be rendered in a drop-down. The code for this is shown in Listing 9-5.
Listing 9-5. The CreateChildControls Code to Call GetDevices
protected override void CreateChildControls()
{
base.CreateChildControls();
Label tableDescription = new Label();
tableDescription.Text = "Devices Available: ";
DropDownList deviceDropDown = new DropDownList();
deviceDropDown.DataSource = GetDevices();
deviceDropDown.DataBind();
this.Controls.Add(tableDescription);
this.Controls.Add(deviceDropDown);
}
Exercise 9-5. Using the BizTalk RFID Proxy Assemblies in a Web Part
This exercise demonstrates the steps needed to reference the BizTalk RFID web proxy assemblies and call them from the SharePoint web part built in Exercise 9-4.
- Open the Visual Studio project created in Exercise 9-4.
- In the project, add the following assemblies as references (see Figure 9-22). All of these are available in
$:Program FilesMicrosoft BizTalk RFIDin.
Microsoft.SharePoint.dll: This assembly gives access to all of the SharePoint classes needed for a basic web part.System.Web.dll: This assembly will enable the inclusion of a configurable field in the web part settings within the SharePoint user environment.Microsoft.RFID.Design.dll: This assembly contains the classes that will be used in the administrative functions within the web part.Microsoft.RFID.ManagementWebServiceProxies.dll: This assembly allows for the remote interaction with the BizTalk RFID API.Microsoft.RFID.SpiSdk.dll: This assembly has a number of base classes needed by the other RFID assemblies.Microsoft.RFID.Utl.dll: This assembly has a number of base classes needed by the other RFID assemblies.
Figure 9-22. Referencing the proxy assemblies in the web part project
Microsoft.RFIDassemblies are deployed to the global assembly cache (GAC) or copied to the SharePointbinfolder. The web part will not execute properly if the assemblies cannot be found during runtime.- Add the following
usingdirectives to the web part for access to the proxy functionality:
using Microsoft.SensorServices.Rfid.Management;using Microsoft.SensorServices.Rfid.Runtime;using System.IO.SensorServices.Rfid.Client;using Microsoft.SensorServices.Rfid;using Microsoft.SensorServices.Rfid.Design;using Microsoft.SensorServices.Rfid.Dspi;- To get a list of devices, add the method shown in Listing 9-4. To call this method, update the
CreateChildControlsmethod with the code shown in Listing 9-5.- Recompile and redeploy the web part assembly. The outcome should look like that shown in Figure 9-23.
Figure 9-23. The GetDevice result shown in the SharePoint web part
Extending the Web Part to Use a Custom Web Service
With the assumption that the BizTalk RFID web service proxy classes are not an option for interacting with the host machine, the discussion will now turn to implementing an intermediary web service that will broker the calls. This allows all permissions to be handled by IIS, and the functionality of the RFID API to be available across distributed clients. This section will demonstrate how to create the web service and call the web service from the SharePoint web part created earlier in this chapter.
The code shown in Listing 9-6 is the complete code for the web service. It takes little more than referencing the BizTalk RFID assemblies and adding a web method to allow for the functionality needed. The steps in Exercise 9-6 outline how to call the web service from the SharePoint web part, instead of using the web service proxy assemblies.
Listing 9-6. The Intermediary Web Service
using System;
using System.Web;
using System.Web.Services;
using System.Web.Services.Protocols;
using System.Collections;
using Microsoft.SensorServices.Rfid.Management;
using Microsoft.SensorServices.Rfid.Runtime;
using System.IO.SensorServices.Rfid.Client;
using Microsoft.SensorServices.Rfid;
using Microsoft.SensorServices.Rfid.Design;
using Microsoft.SensorServices.Rfid.Dspi;
[WebService(Namespace = "http://tempuri.org/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
public class Service : System.Web.Services.WebService
{
public Service () {}
[WebMethod]
public ArrayList GetDevices()
{
ArrayList results = new ArrayList();
DeviceManagerProxy proxy = new DeviceManagerProxy("localhost");
DeviceDefinition[] devices = proxy.GetAllDevices();
for(int x=0; x<devices.Length; x++)
{
results.Add(devices[x].Name);
}
results.Sort();
return results;
}
}
Exercise 9-6. Calling a Custom RFID Web Service from the Web Part
This exercise demonstrates the steps needed to create a web service that references the BizTalk RFID web proxy assemblies and call this web service from the SharePoint web part built in Exercise 9-4.
- Begin by creating a new web service project in Visual Studio.
- Add the BizTalk RFID assembly references to the web service project as outlined in step 2 of Exercise 9-5.
- Set the code of the web service to that shown in Listing 9-6.
- Build the web service project and make sure that it can be accessed as a web service from IIS. This can most easily be done by opening IIS from Administrative Tools and configuring the directory to be an application (see Figure 9-24).
- With the web service deployed, a reference can be made to it in the SharePoint web part project. To do this, right-click the References folder in Solution Explorer and select Add Web Reference. Add a reference to the new web service. The web service should appear as shown in Figure 9-25.
Figure 9-24. Setting the web service properties in IIS
Figure 9-25. Adding a reference to the new web method
- Update the code in the
CreateChildControlsmethod to call the web service. The code should look like that shown in Listing 9-7.Listing 9-7. The CreateChildControls Code to Call GetDevices in the Web Service
protected override void CreateChildControls()
{
base.CreateChildControls();
Label tableDescription = new Label();
tableDescription.Text = "Devices Available: ";
DropDownList deviceDropDown = new DropDownList();
// instantiate the web service
SharePointRFIDWS.Service ws = new SharePointRFIDWS.Service();
ArrayList devices = new ArrayList(ws.GetDevices());
deviceDropDown.DataSource = devices;
deviceDropDown.DataBind();
this.Controls.Add(tableDescription);
this.Controls.Add(deviceDropDown);
}- Redeploy the web part and refresh the SharePoint web site. The drop-down should appear (exactly as it did before) as shown in Figure 9-23.
Conclusion
There are numerous ways to integrate systems throughout the enterprise and across networks. The intent of this chapter was to introduce two core approaches that would illustrate many of these methods. While SharePoint 2007 is a popular portal, and will likely be used in a number of BizTalk RFID implementations, we hope that you’ll be able to extend the concepts to apply to your own situations. The most important concept to leave this chapter with is how to connect from remote systems to access the data needed. Some data is most easily accessed directly from SQL Server (especially in read-only types of implementations). Other information is better accessed via the BizTalk RFID API using the proxy assemblies (especially when enabling administrative read-write capabilities).
Remember that the initially obvious approach to integration is not always the most appropriate. Take time to think through the architecture and requirements, and make sure that the implementation being built today matches the short- and long-term needs of the solution at hand.
CASE STUDY: MONITORING INVENTORY THROUGH SHAREPOINT SERVER
Industry: Retail.
Overview: For one large retail music vendor, it was becoming apparent that CDs were being lost for a variety of reasons, including lost shipments from the warehouse, poor inventory management, and theft. By tagging each CD case with an RFID tag, inventory could be more closely monitored. The retailer then wanted to let specific retail outlets monitor their own merchandise. The data was being captured by BizTalk RFID and stored on a centralized server. The retailer moved to implement SharePoint 2007 to quickly deploy a solution that allowed different retailers access to view information that specifically related to them. This information included times of shipment, total number of items shipped, current expected inventory, and other appropriate metrics.
Results: The organization as a whole increased visibility into the entire inventory control process, and was better able to monitor what occurred during shipments. The different retail outlets were given far more insight into their expected inventory, and were better able to control costs around inventory management.