Presence Scenarios: Publication
Custom applications may publish category instances that are recognized and displayed by Office Communicator or they may publish category instances that are ignored by Office Communicator and are only subscribed to by other custom applications. Some applications publish category instances such that useful information is displayed by Office Communicator, but additional information is available for custom applications that subscribe to the same data.
Custom applications typically publish states and notes, but they can also publish device instances and custom categories. To publish to a custom category, you need to register the new category with Office Communications Server. This cannot be accomplished by a client application, but requires direct interaction with Office Communications Server.
Applications can publish to the containers that are used by Office Communicator, or they can publish to other containers whose members are added by the application. Publishing a state with an instance ID that Office Communicator uses to an Aggregation container (ID of 2 or 3) results in the Office Communications Server’s Aggregation script aggregating that state and republishing to other containers, just as it does for Office Communicator.
When publishing a state with availability, applications can take advantage of the fact that Office Communicator interprets a range of values to be one state in order to incorporate additional information. For example, the range 6500 to 7499 represents “Busy”. A custom application might publish a user state with an availability of 6100 to indicate further information, such as “Busy working with application”. In Office Communicator, this is displayed as “Busy”, but the custom application might display this additional information to other users who are using the application. The XML for this state would look as follows:
<st:state xsi:type="aggregatestate" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:st="http://schemas.microsoft.com/2006/09/sip/state" > <st:availability>6100</st:availability> </st:state>
Custom activities can be created by publishing a state that defines an activity token (the string to be displayed) and an availability range. When the Aggregation Script calculates the availability of a presentity, it checks the availability ranges of all the activities. If the availability falls within one or more ranges, it displays the activity token from the activity whose minimum availability value is closest to the availability that is being displayed.
There is no reason for an application to publish to the Blocked container used by Office Communicator. However, you can create your own Blocked container by choosing a container ID that is higher than 32000 and higher than all the other container IDs that you use, and then adding members to it. To block them from seeing other category instances, publish an availability of Offline and publish blank category instances for the other category instances you want to block.
Consider a call center where users get phone calls and use a custom application to fill out data that they receive from callers. When they are on the call, Office Communicator displays that they are on the phone and therefore other people do not disturb them. When they finish with the call, the custom application asks them to fill in some final information in a form. During this time, it is important that they are not disturbed so that they do not forget any details of their call. Therefore, Office Communicator should display a state of “Do Not Disturb” until the final form has been completed.
For this scenario, when the custom application displays the final form, it creates a state category instance and sets the availability to a value between 9,000 and 11,999, which corresponds to “Do Not Disturb”. By using a specific number, such as 9423, it indicates to other custom applications that the user is in the process of filling out the final form. In addition, the application publishes an activity called “Filling out the final form”, with a range of 9423 to 9425, allowing for three potential states that correspond to filling out the final form. Because the availability value of 9423 falls in this range, this results in the string “Filling out the final form” being displayed in Office Communicator. The state is then published to container 2 (Aggregation 1) and the Aggregation Script aggregates and publishes it to containers 100, 200, and 400 (Public, Company, and Personal). The same state could be published to container 3 (Aggregation 2), and the Aggregation Script would then aggregate and publish it to container 300 (Team), but the application designer might instead decide that interruptions from the team are acceptable while filling out the final form. In this case, a state with an availability of 6900 (Urgent Interruptions Only) should be published to container 3, which displays with a “Busy” icon rather than a “Do Not Disturb” icon. These states have an expiration type of user so that they are removed when the user logs off.
The following is the XML that would be published to container 2 to indicate the availability and the activity.
<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>9423</availability> <activity minAvailability="9423" maxAvailability="9425"> <custom>Fill out the final form</custom> </activity> <endpointLocation></endpointLocation> </state>