Subscriptions for Administrative Types

The API includes a set of methods that allow you to write custom functionality to allow end users to subscribe to an administrative type and not only to business objects. For example, a user could subscribe to the create event for a part, and then be notified whenever any part is created. The standard usage requires the user to subscribe to a specific object for specific events.

To define a type-level subscription event, see the instructions in Configuring Subscription Events. You must use the Global=true setting on the event command for the event to be configured on the type and not only on business objects.

For a type-level subscription, you must create a Publish Subscribe object using the symbolic name of the administrative type. The data model looks like this:



Although the Admin Type is not connected to the Publish Subscribe type, the relation is enforced because the name of the Publish Subscribe object must be the symbolic name of the administrative type.

For example:

Type: Publish Subscribe

Name: type_part

This Publish Subscribe business object would be connected to an Event object using the Publish relationship. The Event object must have the Event Type attribute set, for example Create, and the Originator (the person who subscribed to the event).

For notifications triggered by subscriptions, you can set the Notification Type attribute on the Subscribed Person relationship with one of these range values:


  • Email
  • IconMail
  • Both (default)

This example shows the data model for a subscription:



In this example, whenever a part is released, the DesignEngineer receives a notification by IconMail.

Event subscriptions on administrative types follow the type hierarchy--that is, all subtypes of Part inherit the defined subscription. A user can subscribe to a subtype when the parent type has an event command configured using the Global=true setting. By default, the Global setting is set to false.

Triggers also follow the type hierarchy. For example, if a Delete trigger on a the Part type is configured to send out a notification, then child objects of Part, such as Hardware Part inherit that trigger. Any triggers defined on the child object override an inherited trigger. When you define your triggers, make sure to include any logic from a parent type in the trigger for a child type, unless you explicitly do not want to retain that functionality.

See Triggers, for more details.

To support this custom functionality, use the emxSubscriptionUtilBase JPO, which includes these methods:

Method Description

subscribeOnObject

Creates subscription Event objects for the context user on a business object.

subscribeOnType

Creates subscription Event objects for the context user on an administrative type.

deleteSubscribeOnObject

Removes the subscription Event from a business object for the context user.

deleteSubscribeOnType

Removes the subscription Event from an administrative object for the context user.

getObjectNotifications

Queries all notifications (IconMails) generated by the object passed to the method. The method can filter the result based on the Event and Date range in which the notification was generated (Event and Date range must also be passed to the method). The results are returned as a maplist of IconMail details contained in a map of key/value pairs.

getTypeNotifications

Queries all notifications (IconMails) generated by the administrative type passed to the method. The method can filter the result based on the Event and Date range in which the notification was generated (Event and Date range must also be passed to the method). The results are returned as a maplist of IconMail details contained in a map of key/value pairs.

For details of the method signature and returned data, see the API documentation.