This chapter contains the following topics:
The EnterpriseOne Orchestrator Monitor (P980060X) is an EnterpriseOne application that enables you to perform a health check of notifications in your EnterpriseOne Orchestrator environment. It provides information about which notifications are performing well and which ones might need fine tuning, as well as details about exceptions so that you can take corrective actions to resolve any issues. For more information, see "Orchestrator Health and Exception Monitoring" in the JD Edwards EnterpriseOne Tools Orchestrator Guide.
Notifications and schedules, like all other orchestration components created in the Orchestrator Studio, are stored as user defined objects (UDOs) in EnterpriseOne. Each orchestration component type is managed as a separate UDO type in EnterpriseOne.
Storing notifications and schedules as UDOs enables you to use the following EnterpriseOne administration tools to manage the life cycle and security for orchestration UDOs:
Object Management Workbench - Web (P98220W)
Use this application to move orchestration UDOs between projects, check out and check in objects, and transfer objects between path codes. After Orchestrator Studio users create and test orchestrations in a test environment, use P98220W to transfer the objects to an AIS Server in a production environment. See the JD Edwards EnterpriseOne Tools Object Management Workbench for the Web Guide for more information.
User Defined Object Administration (P98220U)
An administrator or person in a supervisor role uses this application to approve or reject orchestration UDOs for sharing. Typically, you can inspect UDOs in P98220U before approving them or rejecting them. However, you can only inspect orchestration component UDOs in the Orchestrator Studio. See the JD Edwards EnterpriseOne Tools Using and Approving User Defined Objects Guide for more information on how to use P98220U.
Security Workbench (P00950)
Use Security Workbench to set up UDO feature, UDO action, and UDO view security, which authorizes access to the Orchestrator Studio design pages and determines the actions users can perform in the design pages. See Setting Up UDO Security for Notifications and Schedules in this guide for more information.
It is recommended to set up different instances of the AIS Server: one instance for designing and testing notifications and another instance for production. Running two instances can also help with troubleshooting notification issues in a production environment. In the Object Management Workbench - Web application, you can move a notification from a production environment to a test environment for troubleshooting.
Out of the box, Orchestrator Studio users do not have access to Orchestrator Studio design pages or permission to create, publish, or modify orchestration UDOs. Access to the design pages and authorization to work with orchestration UDOs is controlled through UDO security in the EnterpriseOne Security Workbench (P00950).
Notifications and schedules are managed as separate UDO types. You have to set up UDO security for notifications and schedules if you plan to use them. If you want to invoke an orchestration from a notification, you must also set up permissions to use the other orchestration components.
Before setting up UDO security for an orchestration UDO type, that orchestration UDO type must be set up with the proper "Allowed Actions" in the OMW Configuration System (P98230) application. See "Define Allowed Actions for UDO Types" in the JD Edwards EnterpriseOne Tools Security Administration Guide for more information.
The following sections provide details and recommendations for setting up UDO feature, UDO action, and UDO view security for notifications and schedules.
You must use UDO feature security to activate notification and Schedule design pages. Out of the box, the design pages are not activated.
Because development of a notification can sometimes require other types of UDOs (for example, Watchlists, schedules, orchestrations), you must activate all pertinent UDOs through UDO feature security. If you do not activate these through UDO feature security, users cannot access the associated components and component design pages.
UDO feature security is NOT set up by user, role, or *PUBLIC. It is a system setting for activating or deactivating notifications and schedules in the Orchestrator Studio.
UDO action security controls the actions users can perform in the Orchestrator Studio, or in other words, the buttons users can use in each component design page. You must set up UDO action security for each component type that you are going to use with your notifications (for example, notifications, Watchlists, schedules, rules, orchestrations).
Recommendation: To simplify UDO action security for Orchestrator Studio users, it is recommended that you grant "Create, Publish, Modify" permissions to all Orchestrator Studio users for each orchestration component type. Also, users must assign a product code to each orchestration component that they create. This gives you the option to set up UDO action security by product code so that all users can work with orchestration components associated with a particular product code.
UDO view security determines which Orchestrator Studio users are authorized to view UDOs that have been shared. UDO view security is set up by user, role, or *PUBLIC. You can set up UDO view security for each shared notification or schedule or for all shared UDOs of a particular UDO type. Again, you need to consider which UDOs are used by your notifications and ensure that UDO view security is set up properly.
See "Managing UDO View Security" in the JD Edwards EnterpriseOne Tools Security Administration Guide and "Managing Orchestrator Studio Security" in the JD Edwards EnterpriseOne Tools Orchestrator Guide.
The notifications that you design will publish information from your JD Edwards system to your subscribers. Therefore, you must be aware of JD Edwards security so that the subscribers get the information they need and do not get the information from which they are secured. In general, the security of your notifications will depend on two things:
The resources or objects that you include in your notification, such as Watchlists or orchestrations, and the resources that they, in turn, invoke.
The user ID under which the notification runs.
As described in Creating a Notification, if your notification is set to "Run as Subscriber" then the notification will run under the user ID of each person who subscribed to the notification. Therefore, all subscribers need authority to access all objects upon which the notification depends.
If the notification is not set to "Run as Subscriber" then the notification will run under the credentials of the user who started the scheduler (proxy user). Therefore, that user ID will need authority to access all objects upon which the notifications depend.
Oracle recommends that your proxy user's data security mirrors that of the notification's subscribers. This ensures that the data subscribers receive in the notifications is appropriate for them. For example, if your subscribers only have access to sales information for a certain region, make sure that your proxy user does not have global access to sales information. Give careful consideration to data security concerns when deciding to run your notifications as a proxy user.
As described in Creating a Notification, you can include a Watchlist or an orchestration in your notification that determines when a notification is sent and what information is included in the message. Watchlists and orchestrations are both UDOs and are subject to UDO security. Also, the schedule that you assign to the notification is a UDO.
If you revoke a user's existing view security, make sure you consider any notification subscriptions they may have. If the Run As Subscriber option is enabled, the subscriber will see that the subscription is no longer valid in the Subscription Manager. However, if the Run As Subscriber is not enabled for that notification, that user may continue to receive notification messages even though they no longer have view security. To ensure that subscribers no longer receive notifications after their view security has been revoked, copy the original notification using the Save As feature in Orchestrator Studio and delete the original notification. This will force subscribers to resubscribe to the new notification.
The AIS Server caches all orchestration files processed by the Orchestrator. If Orchestrator Studio users modify notification components that are currently in use, an administrator must clear the AIS Server cache for the modifications to take effect. Clearing the cache forces the AIS Server to reload files from disk to cache.
Regardless of the method you use, Oracle recommends that you clear the cache only on an AIS Server instance used for developing and testing notifications.
See "Clearing Orchestration Cache on the AIS Server" in the JD Edwards EnterpriseOne Tools Orchestrator Guide for more information.