Example: Platform and application communication for recurring events
Occurrences of a recurring event do not necessarily exist in the database. However, applications need to have a handle to those occurrences for any number of business processes.
Perhaps this need is best described by example. Consider the recurring event described in the prior section. It was a recurring weekly event starting in 1920 and having no end date. When the user views the April 2011 calendar UI, they need to be able to remove the occurrence on April 6th, 2011. Since the platform only understands event at an abstract level, then it is the application that handles the business logic around reacting to that user action. For example, there may be food service to be cancelled and notifications to be sent.
An application can see the event details with the triCalendarEvent platform business object. The platform uses the triCalendarEvent business object to pass event occurrence data to applications. The triCalendarEvent business object resides in the System module. The following table shows the fields in triCalendarEvent and what they mean:
| Business Object Field Name | Description |
|---|---|
| triEventIdTX | This is the ID of the affected event. If the event is for a non-exception occurrence of a recurring event, this field has no value. In all other cases, this ID is the smart object ID of the event record. |
| triRecurrenceIdTX | In the case the affected event is an occurrence (exception or non-exception) of a recurring event, this is the smart object ID of the original recurring event. |
| triStartDT | This is the start date-time of the affected occurrence. |
| triEndDT | This is the end date-time of the affected occurrence. |
Platform features use this business object to communicate occurrence information from the platform to an application. Here are some examples:
- If a user takes action on an occurrence
in a Calendar UI, the platform communicates that user action to an
application by way of workflow input parameters and a triCalendarEvent
record. The following figure shows a workflow variable being assigned
from an expression:
Figure 1. Example of using parameters and return values 
- Applications can use formula functions to request occurrence information for events that do not necessarily exist in the database. One such example is the getEventsForResource() function which, given a resourceId and a few other parameters, returns a collection of triCalendarEvent records that can then be processed in a workflow.