Presence Scenarios: Custom State
This topic contains two scenarios where custom states are used.
Consider a business where employees work on processing documents using a custom application. At any given time, an employee should only be working on one document. As questions about the documents come up, the employees call a manager to get assistance. The custom application knows which document each employee is working on. When they call or message the manager, a different custom application on the manager’s computer automatically brings up the document for the manager to look at, thus saving the manager time in locating the appropriate document.
In this scenario, the employees’ custom application could create a new container with an ID of 501, add the manager as a member, and then publish it to container 0. When a new document is opened, the application creates a note category instance with an ID that is not being used by Office Communicator, such as 0x60000000. An ID for the document is converted into a string and set to be the activity property or attribute for the category instance. The category instance is published to container 501 with an expiration type of static so that it remains in the container until a more recent version of the same state is published.
The manager’s custom application reacts to events when the category instance is added or modified. It stores the ID in a table along with the employee’s SIP URI. When the application detects an incoming phone call or instant message from that SIP URI, it retrieves the document using the ID and displays it.
An example of the XML data is as follows. The category ID of 0x6000000 is expressed as 100663296, and the document ID is Doc579370945 in the block tag of the note.
<publication categoryName="note" instance="100663296" container="501" version="0" expireType="static"> <note xmlns="http://schemas.microsoft.com/2006/09/sip/note"> <body type="personal" uri="" startTime="2009-02-20T21:56:36Z" endTime="2009-02-20T21:56:36Z">Doc579370945</body> </note> </publication>
Note that in this scenario, none of the published information is displayed by Office Communicator.
A taxi dispatcher has software that displays which taxis in the fleet are available and their current GPS position. The dispatcher wants to be able to use custom software to display the taxis on the map, but also wants Office Communicator to display their availability and what municipality they are currently inside.
The software in the taxi publishes availability based on whether the taxi has a fare or not. As in the first custom application example, state category instances are published to containers 2 and 3. Availability can be set to convey additional information, such as an availability of 6012 could represent having a general customer, but an availability of 6013 could indicate taking a customer to the airport. The dispatcher’s software could distinguish between the two and make use of the data, but Office Communicator would simply display both of these states as “Busy”. The XML for the state with availability of 6012 is as follows.
<state xmlns="http://schemas.microsoft.com/2006/09/sip/state" manual="true" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="userState"> <availability>6012</availability> </state>
For publishing location information, the application can use a note for information to show up in Office Communicator and can use a custom state for specialized GPS location data. The application determines what municipality the taxi is in and sets a note category instance’s body property or attribute to the name of the municipality so that it is visible in Office Communicator. However, to publish more detailed GPS information, it publishes a state category instance with an ID that Office Communicator is not using, such as 0x29000000. The GPS information is converted into a string and the EndpointLocation property or attribute is set to that string. The category instance is published to a container to which the dispatcher is a member. This is not information that should be aggregated; therefore, instead of publishing to container 2 or 3, you should publish to whichever container contains the dispatcher as a member.
The XML data for the note that publishes the municipality might be:
<note xmlns="http://schemas.microsoft.com/2006/09/sip/note"> <body type="personal" uri="" startTime="2009-02-20T22:37:15Z" endTime="2009-02-20T22:37:15Z">Redmond, WA</body> </note>
The XML data for the state that publishes the GPS data might be:
<state xsi:type="aggregateState" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/2006/09/sip/state"> <availability>6012</availability> <endpointLocation>N 47 deg 36.641 W 122 deg 19.868</endpointLocation> </state>