This chapter covers the following topics:
The Calendar Administrator, typically the system administrator or workflow administrator, has the privilege to grant approval or rejection to new group and public calendar requests. When new group or public calendar requests are generated, the Calendar Administrator receives workflow notifications for approval. Therefore, the user who becomes the Calendar Administrator must exist in Oracle Human Resource Management System (HRMS) as an employee resource.
Use the following procedures to create a Calendar Administrator:
Assigning Appropriate Responsibilities:
After identifying an employee resource to become a Calendar Administrator, implementors or system administrators must assign appropriate responsibilities to the employee. In order to receive notifications and create calendar general users, the Calendar Administrator must have the following responsibilities:
System Administrator. Use this responsibility to grant the HTML Calendar access responsibilities to calendar general users.
CRM Application Foundation User. Use this responsibility to access the HTML Calendar and HTML Resource Manager modules.
Optionally, use the JTF HTML Calendar User responsibility if you are only to access the HTML Calendar module.
Workflow User Web Applications. Use this responsibility to verify workflow processes, and to view workflow notifications. If it is configured correctly, you can view these notifications from your personal homepage.
Preferences (Oracle Self-Service Web Applications). Use this responsibility to define user preferences, for example, send or do not send e-mail notifications. To receive workflow notifications, select General Preferences and change the value in the “Send me electronic mail notifications” field to “Do not send me mail”. This tells the system not to send you e-mail notifications, but instead to send them to your notifications page.
Associating the Calendar Administrator with Appropriate Profile Options
After creating the Calendar Administrator, implementors must set the "JTF HTML Calendar: Administrator" profile option to the person who will be the Calendar Administrator. This grants the profile option to the Calendar Administrator, so that she or he can grant approval for new group and public calendar requests.
Additionally, if the standalone HTML Calendar module is used as default application and responsibility after signing on, then the following profile options also need to be assigned to the Calendar Administrator:
JTF_PROFILE_DEFAULT_RESPONSIBILITY (22946)
JTF_PROFILE_DEFAULT_APPLICATION (690)
HTML Calendar allows only one Calendar Administrator in the system to be responsible for any new group or public calendar requests; therefore, in the case of the absence of the Calendar Administrator, the Calendar Administrator or whoever has the JTF_CALENDAR_ADMIN role can perform the update by changing the name in the Calendar Administration window.
The JTF_CALENDAR_ADMIN role can be assigned through the System Administrator Console by the system administrator. A user without this role attempting to access the Calendar Administration window will see an error message saying that "You don't have sufficient privileges to view this page."
Once you update the Calendar Administrator, the JTF_CALENDAR_ADMIN role is automatically assigned to the new Calendar Administrator, and is revoked from the old Calendar Administrator. Therefore, the new Calendar Administrator can get access to the Calendar Administration window while the old Calendar Administrator cannot. All the new group calendar requests should be sent to the new Calendar Administrator through workflow notifications.
Assign JTF_CALENDAR_ADMIN Role to a User
To grant the JTF_CALENDAR_ADMIN role to a user, log in to the System Administrator Console as a system administrator. Select Users tab > Registration subtab > User Maintenance. Query up the user name and then click the Roles button to access the User-Role Mapping window. Select the JTF_CALENDAR_ADMIN role from the Available Roles block to move the role to the Assigned Roles block. Click the Update button to complete the change. The user will have access to the Calendar Administration window.
In addition to scheduled appointments and tasks, HTML Calendar provides the ability to allow users to view calendar events, such as campaigns, on their calendar views.
In order to use this functionality, the integrated applications have to perform the following tasks:
Identify resource groups to which they would like to publish events and add CALENDAR_ITEMS usage to the groups.
Make sure that business objects (known as events in calendar) that are published are valid JTF_OBJECTS with all the following metadata defined:
SELECT_NAME
SELECT_ID
FROM_TABLE
OBJECT_CODE
WHERE_CLAUSE
WEB_FUNCTION_NAME
WEB_FUNCTION_PARAMETERS
WEB_HTML_CALL
Populate the JTF_CAL_ITEMS_B table using the JTF_CAL_ITEMS_PUB API.
In order to view the calendar events in the personal calendars, calendar users must also meet the following conditions:
Users must belong to resource groups to which the event is published.
Users must have the "Display Events" set to yes in the calendar personal preference page from the Profile navigation link.
Users must further personalize how these calendar items will be displayed in their personal calendars by selecting the desired color and prefix text.
This feature will work only when integrated applications implement the functionality and follow the required steps.
Oracle Marketing is one of the applications that is currently implementing this functionality. Please refer to Oracle Marketing Implementation Guide for more details.
The Calendar module, leveraging the Oracle Workflow Business Event System, publishes business events for appointments such as creating, updating, and deleting an appointment, adding and removing an invitee, as well as responding to an invitation when the following conditions occur from APIs, application user interfaces (UIs) in HTML or the Oracle Applications Framework based modules:
An appointment is created, updated, and deleted
An invitee is added to or removed from an appointment
An invitee accepted or rejected an appointment
Applications that contain data directly affected by these events can subscribe to them and synchronize or modify their data accordingly.
For example, if an appointment is created with invitees, this action is published or "raised" as a business event. This event can be, for example, captured to send relevant workflow notifications. If an appointment is created, updated, or deleted, this action is raised as a business event.
The Oracle Workflow Business Event System is an application service that leverages the Oracle Advanced Queuing (AQ) infrastructure to communicate business events between systems. The Business Event System consists of the Event Manager, which allows you to register subscriptions to significant events, and workflow process event activities, which allow you to model business events within workflow processes.
The Event Manager contains a registry of business events, systems, named communication agents within those systems, and subscriptions indicating that an event is significant to a particular system. Events can be raised locally or received from an external system or the local system through AQ. When a local event occurs, the subscribing code is executed in the same transaction as the code that raised the event, unless the subscriptions are deferred.
See Oracle Workflow Developer's Guide for detailed information about Oracle workflow business event system, and subscriptions.
When an appointment is created, updated or deleted, an invitee is added or removed, as well as an invitation is responded from APIs, or application user interfaces (UIs), the Calendar module will publish the following events:
| Event Name | Display Name | Description |
|---|---|---|
| oracle.apps.jtf.cac.calendar.createAppointment | Appointment created. | This event is published when an appointment is created. |
| oracle.apps.jtf.cac.calendar.updateAppointment | Appointment updated. | This event is published when an appointment is updated. |
| oracle.apps.jtf.cac.calendar.deleteAppointment | Appointment deleted. | This event is published when an appointment is deleted. |
| oracle.apps.jtf.cac.calendar.addInvitee | Invitee added. | This event is published when an invitee is added. |
| oracle.apps.jtf.cac.calendar.respondInvitation | Invitee responded. | This event is published when an invitee is responded. |
| oracle.apps.jtf.cac.calendar.removeInvitee | Invitee removed. | This event is published when an invitee is removed. |
For each appointment business event, the owner name is Calendar, the owner tag is JTF and the default status is Enabled.
Event name represents the name of a business event that is an occurrence in an application or program that might be significant to other objects in a system or to external agents. Event name must be unique and is case-sensitive; therefore, subscribers must use Event Name for subscription purposes.
The following table contains published attributes for the parameters used to create, update, and delete appointments.
| Parameter Name | Source Table Name | Create Appointment | Update Appointment | Delete Appointment |
|---|---|---|---|---|
| TASK_ID | JTF_TASKS_B | Yes | Yes | Yes |
The following table contains published attributes for the parameters used to add, and remove invitees, as well as respond invitation events. Yes indicates that an attribute is published and No indicates that it is not.
| Parameter Name | Source Table Name | Add Invitees | Respond Invitation | Remove Invitees |
|---|---|---|---|---|
| TASK_ID | JTF_TASKS_B | Yes | Yes | Yes |
| ASSIGNMENT_STATUS_ID | JTF_TASK_ASSIGNMENTS | No | Yes | No |
| RESOURCE_ID | JTF_TASK_ASSIGNMENTS | Yes | Yes | Yes |
| RESOURCE_TYPE | JTF_TASK_ASSIGNMENTS | Yes | Yes | Yes |
All event subscriptions must follow the guidelines mentioned in the workflow development standards. For example, any subscription cannot commit inside the rule function. This can cause unexpected behavior in the workflow or appointment APIs.
In addition, the following subscription guidelines are also used in publishing appointment business events:
Asynchronous Subscriptions
All subscriptions to the events should be asynchronous. The UIs call the APIs, which in turn publish events. Therefore, if the subscriptions are synchronous, the transaction time for the UI will increase.
Returning with success or warning
The rule function of the subscriptions should return success or a warning. It should not return an error. Returning an error disrupts the processing of other subscriptions; therefore, an error should not be returned.
The Rebuilding Intermedia Index for Task Names concurrent program rebuilds the intermedia index so that a user can use the Quick Find to search for new and updated appointments and tasks. Therefore, the concurrent program has to be compiled periodically in order for appointment search to work properly. For more information on running this concurrent program, see the Running the Task Manager Concurrent Program documentation in the Task Manager section.