| Agile Product Lifecycle Management SDK Developer Guide - Developing PLM Extensions Release 9.3.6 E71153-01 ,Oracle and/or its affiliates. All rights reserved. |
|
 Previous |
 Next |
| Agile Product Lifecycle Management SDK Developer Guide - Developing PLM Extensions Release 9.3.6 E71153-01 ,Oracle and/or its affiliates. All rights reserved. |
|
Previous |
Next |
This chapter includes the following:
Understanding Agile PLM Events and Event Framework
Key Components of an Agile PLM Event
Working with Event Context Objects
Working with Event Information and Event Script Objects
In Agile PLM, Events act as trigger points for generating an automation action within the PLM application. Every Event is generated from a source within Agile PLM applications. The source can be a business action triggered by a user, a UI action, or system initiated source such as a timer. These sources can signal other PLM modules that something (an event) has occurred within the application and it may require an action. The required action can be taken by a user or the PLM module. Event-driven applications greatly facilitate the management of event-based integrations and complex event analysis in real time modes.
In the Agile SDK environment, Event framework extends the PX framework which facilitated automating and extending the Agile PLM Applications. Event framework provides a flexible environment for rapid development and deployment of event-driven applications. To support this environment, Event framework provides a comprehensive set of data parameters to create, configure, and execute different types of Agile PLM Events.
Event framework empowers users to configure Events and Event subscribers. The basic components of Event framework are shown in the following illustration and described in the following paragraphs.
In Agile PLM, Event type refers to a particular action, for example, Create Object, Delete Object, Audit for Workflow. Agile PLM provides a list of pre-defined Event types for which an event can occur.
For each Event type, depending on its Handler type, there is a corresponding Java and Script interface for its Event Context object. For example, for Create Object, there is the ICreateEventInfo Java interface and ICreateScriptObj Script interface respectively.
Event type is selected from the drop-down list in Java Client's Create Event dialog when the Event is created. To access this dialog, refer to Agile PLM Administrator Guide. Default Event types and their descriptions is shown in the figure below.
|
Note: You can neither create, or delete these Event types. |
An Event Handler represents a custom action that is called when the Event is raised. They extend the function of an action taken by a user, interface, or the system when the Event is triggered. Information about the Event is passed from the Event to the Handler by the Event Context object. Handlers are invoked by Event Triggers.
The SDK and Event framework support the following Event Handler types:
Java PX - Java PXs are Java process extensions that implement the IEventAction interface in com.agile.px package and trigger the compiled Java code. See "Event Information Objects."
Script PX - Script PXs are Script process extensions based on Groovy script language.
The Groovy script code is directly stored in Agile PLM databases. Event Script objects (Event Script PX handlers) that you develop are text files that are deployed on the Agile PLM server using the Event Management Node in Java Client. For information on submitting the text files, see "Working with Agile PLM Administrator." For information about Groovy implementation in Event framework and Event Script PX development process, see Appendix A, "Altering Existing WSX Code to Interact with JAX-WS-Based Framework."
Notification - Agile PLM can send notifications to users, either when the user is required to act, or to notify the user of actions that have occurred. Notifications can be triggered from the SDK and Script. Event Notifications are addressed in the Agile PLM Administrator Guide. To use the SDK to programmatically send Notifications, refer to ”Sending Notifications with Agile SDK” in SDK Developer Guide - Using Agile APIs.
|
Note: SDK developers use the Java PX and Script PX to extend the capabilities of Agile PLM. The Agile PLM Administrator uses the Notification templates to define and configure Notifications for action or information. |
An Event Subscriber links an Event Handler to a specific Event. Thus, when a particular event occurs, Event Handlers associated with the Event through Event Subscribers are initiated in the order requested by the configuration. The Handler action includes invoking a Java Process Extension, a Script Process Extension, or sending Notifications.
Event Trigger determines when an Event Extension is raised. The Event framework provides the hooks to automate actions when an incident happens. For example, when a change of status occurs, a CEO approval is required, the trigger signals the occurrence of an action which will subsequently notify all Event subscribers for that Event. Most Agile PLM Events are associated with business actions. Examples are:
Create Object Event - associated with the object creation action
Change Status for Workflow Event - associated with the Workflow status change action
Pre - This trigger type signals a point before the occurrence of an action. The Pre trigger is commonly used for events that require data validation or other preparations for the upcoming action. Event Handlers are invoked synchronously from the Pre trigger point.
Post - This trigger type signals a point immediately after the action's changes are committed to the database. The post trigger is commonly used for Events that perform auditing tasks, notifications, and integration tasks with external systems related to the completed action. Event Handlers are invoked synchronously or asynchronously from the Post trigger point.
Event Handlers are invoked synchronously or asynchronously. In general, the term synchronous means it is run as part of the application within the current action. A synchronous operation blocks a process until the operation completes, while an asynchronous operation is nonblocking and only initiates the operation.
In Agile PLM, the difference between the two modes is:
Synchronous - In this mode, the Event Handler is executed in the same thread (as part of the execution of the action taken) as the Agile PLM thread that triggers the event (for example, a change in a Workflow status). The original Agile PLM action will resume after the handler action is completed.
Asynchronous - In this mode, the Event Handler has its own thread (runs independent of the execution of the action taken) and it cannot be stopped once it is started. This transaction is either committed or rolled back based on its own status. The Agile PLM thread that triggers the event will continue to run independently regardless of the Handler action has finished or not (Non-block). Notifications are always handled asynchronously.
PLMs that are configured for operation in clusters, use the Java Message Service (JMS) for messaging purposes within the cluster. JMS is a Java Message Oriented Middleware (MOM) API for sending messages between two or more clients.
In OAS clusters, JMS resources are hosted only on the primary node, or JMS-host. If the primary node is down, asynchronous Events are still triggered on the secondary node and are set to queued status, but they are never executed. Once the primary node is recovered, depending on the implementation of OAS, asynchronous Events can execute and cause the final result, provided they can pick up the queued JMS messages at the time the system went down. Otherwise, these Events remain in the queue and are never executed.
In these situations, you must stop and restart the cluster, starting with the primary node. If you cannot recover the primary, you must configure the primary (the JMS-host) on another node before starting the cluster. Queued Events do not execute if you drop the primary and continue to use the application on the secondary nodes.
|
Note: This constraint is only applicable to the operation of asynchronous Events in OAS clusters. It does not apply to WLS clusters, because WLS supports clustered JMS and has no single ”primary” or ”JMS-host” node. |
Event Error Handling Rule is used with Event Handlers that are executed synchronously. Options are Continue and Stop. The selected option determines the behavior of Agile PLM when an error is encountered while executing the Event Handler. For more information on error handling rules, refer to Agile PLM Administrator Guide.
Continue - In case of error, Handlers with synchronous execution mode will ignore the error during execution.
Stop - If there is an error during the execution of a Handler with synchronous execution mode, the original action and the Event Subscription is ceased.
Event Order is a positive integer that determines the sequential ”Order” in which the Event handler is invoked. Thus, you can control the execution order of Event Handlers when there are multiple Event Subscribers for the same Event type on the same Agile object.
|
Note: If you have both Custom PXs and Java synchronous PXs configured for a Workflow Change Status action, Java PXs always execute before Custom PXs. |
This section answers common questions about the Event framework and Java and Script process extensions.
What are the differences between Custom process extensions and Java process extensions (Java PX)?
Similar to Custom process extensions, Java PXs also extend the functionality of Agile PLM clients through custom actions. This is done by implementing the IEventAction interface in com.agile.px in Event framework. You can use Process extensions to connect the Agile PLM server and Agile PLM users to external systems. In addition, Java PXs contain Event Context objects which provide more information than Custom PXs.
Can I use Agile's Java API within a Java process extension program?
Yes. You can use Agile's Java API and other external Java APIs as you did with Custom PXs.
Do Java PXs have special security requirements?
No, similar to Custom PXs.
How are roles and privileges defined for Java PXs/Script PXs?
By default, a custom action (a Handler) uses the roles of the current user. However, to configure a custom action to have expanded privileges, you can specify the roles required for the Handler in the Java Client. When the Handler is executed, the roles specified for the Handler override those of the current user. Once the Handler is completed, the client reverts to the user's original roles and privileges.
Do user assigned roles override roles assigned to a Java or Script PX during configuration?
No. Roles assigned to a Java or Script PX override the user's original roles. Thus all actions that occurred inside the PX Handler are subject to privileges based on these roles. However, the access of the event context object does not need the privilege check, including the getXXX and setXXX method calls.
How do I configure and deploy a Java process extension?
Similar to Custom PXs, place the JAR file(s) for a process extension in the agile_home/integration/sdk/extensions folder on the application server. Included with the JAR file(s) should be a file named com.agile.px.IEventAction in the META-INF/services directory. The contents of these files are the fully qualified Java class names, one class per line, for an Event action.
After deploying a Java PX on the application server, how do I enable it?
Once Java PX codes are deployed, you can configure them for use within Agile PLM in Java Client by selecting Admin > Settings > System Settings > Event Management > Event Handlers > New > Create Event Handler > Java PX > Event Action.
After deploying JAR file(s) for a Java PX Handler, is it necessary to update the application server classpath?
No. The classpath is updated automatically by a special-purpose classloader. The classloader extends the application server classpath with any classes located in agile_home/integration/sdk/extensions (or the location specified for the sdk.extensions property in the agile.properties file).
Which Custom PXs can I migrate to the Event framework?
The Event framework supports migrating only Custom Action PXs. These are PXs that are initiated from the Actions Menu, Tools Menu, and Change Status for Workflow.
The corresponding Event types are: Extend Actions Menu, Extend Tools Menu, and Change Status for Workflow.
What error handling rules must the developer/user specify?
For Synchronous Handler, the user must specify the error handling rule to determine how the system reacts if it encounters an error while processing this subscription. The error handling rule only applies to synchronous Handlers. It supports the following two choices, Stop and Continue.
Agile PLM stops any further event processing, and then returns to the originator who raises the event. All remaining synchronous subscribers are not called.
In the case of pre-event, upon receiving the error from the subscriber, the originator simply throws the error to the client that initiates the action and the original action is not performed. The system may also rollback changes made by Handlers. However, whether the transaction can be rolled back or not depends on the Handler type. If it is a Java PX Handler, no transaction rollback is performed because the Handler is the SDK program which has its own transaction.
Do I need to deploy script PXs?
No, Scripts are pasted in the editor in the Script Handler and Agile PLM will store the code in the database. Consequently, programs are delivered in plain text files and not in object code.
Can I send Notifications using Event Handler?
Yes, you can send a Notification from a Java PX and a Script PX.
When should I use scripting?
Use Scripts for prototyping, simple operations, and test driven developments.
Do I need to compile my Script code?
No, Script code is validated for syntax errors when you save it in the Handler and will be compiled when the Event is triggered.
What are Dirty files and related methods and interfaces?
They are documented in the Javadoc generated SDK documentation folder under IEventDirtyRowFileUpdate. To access the SDK samples folder, see the Note in "Client-Side Components."
Can a single action trigger multiple Events?
Yes, for some actions such as Update Multiple Attachment Rows, a single action will trigger multiple Events. In addition, if there are Subscribers for Pre and Post trigger types, then the order in which the Subscribers are invoked can vary depending on the PLM client, the action, and the object type. For example, if you are deleting three rows from an Attachment Table with one Subscriber for the Pre trigger and one Subscriber for the Post trigger, the behavior in PLM clients are as follows:
Web Client - A single Update Table Event is triggered
Java Client - Three Update Table Events are triggered and one Event for each deleted row as shown below:
For Changes, Items, Transfer Orders, MFR Parts, Suppliers, Sites, Customers, and Package objects, the sequence of the Event Subscribers that are invoked is:
Pre (handler from the pre trigger subscriber - for the first row)Pre (handler from the pre trigger subscriber - for the second row)Pre (handler from the pre trigger subscriber - for the third row)Post (handler from the post trigger subscriber - for the first row)Post (handler from the post trigger subscriber - for the second row)Post (handler from the post trigger subscriber - for the third row)
For Product Service Requests, Quality Change Requests, MFRs, Users and User Groups, the sequence is: Pre - Post - Pre - Post - Pre - Post
Best Practices?
What should we avoid in Handlers for Pre-Event?
Use Pre-Event mainly for validation. Although you can modify the Context object, you should avoid direct object updates using SDK calls. (Sometimes, using SDK calls in Pre-Event may cause object version mismatch)?
Subscriber ordering?
Sometimes, for the same event type, you can have the Event Subscribers at Base Class level, Class level, and Subclass level. For example, you may have several Event Subscribers for Create Object Event Type. One at Item Base Class level, one at the Part Class level, and one at the Part Subclass level. If you prefer to execute the Subscribers based on Class hierarchy, it is recommended to allocate an order range for the Base Class, each Class, and each Subclass. For example, you can assign the following range for different Hierarchy levels:Base Class 0 – 99; Class 100 – 199; Subclass 200 – 299
Can I mix Agile SDK calls and Script PX within Script PX?
You can mix the two as long as you don't use both SDK calls and script PX calls to update Agile objects in the same Handler code. To update the Agile object, you can either use SDK calls or update APIs that are supported by Script Context object, but not both.
What are the differences between Variant Management events and other system events?
Variant Management does not have ”Pre” or ”Post” trigger types. Once an event is enabled, it replaces the system behavior instead of extending it.
Variant Management event types are only applicable to the Model part subtype.
The Variant Management event types are not linked to a specific action only.
Variant Management event types support only one specific execution mode (Synchronous) and error handling rule (Stop).
The flowing paragraphs describe the role of Event Context objects, their creation, different Event types, and the information they maintain.
The Context object passes information from the Event to the Handler and between Handlers. When an Event is raised, an Event context object is created. Information maintained by the context object includes Event type, pre- and post-Event triggers, plus business-related data for the given Event, such as the Agile object for which the Event occurred. The business-related data varies based on Event type.
Different Event types have different Context objects. Interfaces for Context objects are documented in Event Information Objects and Event Script Objects. These interfaces are documented in the Javadoc HTML files as Event Information objects (Java interfaces) and Event Script objects (Script interfaces). To find the Javadoc HTML files in the SDK_samples.zip folder, see the Note in "Client-Side Components."
In Event framework, objects passed to Event Handlers (Java PX or Script PX) by Context objects contain ”Persistent" and ”Transient” data.
|
Note: For Variant Management all Context objects contain ”Transient” data only. |
Persistent data - This is data that is already in PLM databases. All Agile SDK APIs and Process Extensions including Web or URL extensions deal with this type of data. When you use getDataObject() to get the values of an IDataObject object, the data you get is already in the database, hence ”Persistent.”
|
Note: Only the getDataObject()method returns Persistent data. Other context object get data methods will return Transient data unless stated otherwise in the Javadoc API definition. |
Transient data - This is data that is not in the PLM database as yet and is in a state of change. Transient data contains information about user requests for the action that triggered the Event.
When the Event is triggered, Agile PLM creates Transient data in the Event Context object. The same Transient data is passed on by the Context object to all Handlers for ”Pre” and ”Post” unless specified otherwise in the Javadoc API definition.
|
Note: You must not modify Transient data in the ”Post” Event triggering instance. If modified, it will throw an exception. Variant Management events do not have ”Pre” or ”Post” trigger types. Once a Variant Management event is enabled, it replaces the system behavior instead of extending it. |
These are the interfaces for the Java PXs.
| Event Type | Event Information Object |
|---|---|
| ”Approve for Workflow” and ”Reject for Workflow” | ISignOffEventInfo |
| ”Audit for Workflow” | IAuditStatusEventInfo |
| ”Change Approvers or Observers for Workflow” | IChangeAppObserverEventInfo |
| ”Change Status for Sourcing Object” | ISourcingObjectChangeStatusEventInfo |
| ”Change Status for Workflow” | IWFChangeStatusEventInfo |
| ”Comment for Workflow” | IRoutableObjectCommentEventInfo |
| ”Create Object” | ICreateEventInfo |
| ”Create Variant Instance”, ”Derive Variant Model Option BOM”, ”Update Variant Configuration”, ”Validate Variant Configuration”, ”Validate Variant Instance Selections”, and ”Validate Variant Model Option BOM”, | IVMEventObj |
| ”Delete Object” | IDeleteEventInfo |
| ”Escalation for Workflow” | IEscalationEventInfo |
| ”Export Object” | IExportEventInfo |
| ”Extend Tools Menu” and ”Scheduled Event” and the base interface for all Event information objects | IEventInfo |
| ”Get File”, ”Check In Files”, ”Check Out Files”, and ”Cancel Check Out Files” | IFileEventInfo |
| "Incorporate File", "Unincorporate File" | IIncorporateFileEventInfo |
| ”Incorporate Item”, ”Unincorporate Item”, ”Extend Actions Menu”, and ”Compliance Rollup on Object” | IObjectEventInfo |
| ”Promotion Failure for Workflow” | IPromotionFailureEventInfo |
| ”Purge Version Files” | IPurgeFileEventInfo |
| ”Reminder for Workflow” | IReminderEventInfo |
| ”Save As Object” | ISaveAsEventInfo |
| ”Transfer Authority” | ITransferAuthorityEventInfo |
| ”Update Table” and ”Update Relationship” | IUpdateTableEventInfo |
| ”Update Title Block” | IUpdateTitleBlockEventInfo |
These are the interfaces for the Script PXs.
| Event Type | Script Object Interface |
| ”Approve for Workflow” and ”Reject for Workflow” | ISignoffScriptObj |
| ”Audit for Workflow” | IAuditStatusScriptObj |
| ”Change Approvers or Observers for Workflow” | IChangeApproverObserverScriptObj |
| ”Change Status for Sourcing Object” | ISourcingObjectChangeStatusScriptObj |
| ”Change Status for Workflow” | IChangeStatusScriptObj |
| ”Comment for Workflow” | IRoutableObjectCommentScriptObj |
| ”Create Object” | ICreateScriptObj |
| ”Create Variant Instance”, ”Derive Variant Model Option BOM”, ”Update Variant Configuration”, ”Validate Variant Configuration”, ”Validate Variant Instance Selections”, and ”Validate Variant Model Option BOM”, | IVMScriptObj |
| ”Delete Object” | IDeleteScriptObj |
| ”Escalation for Workflow” | IEscalationScriptObj |
| ”Export Object” | IExportScriptObj |
| ”Extend Tools Menu” and ”Scheduled Event ”Event Script objects, also the base interface for all Event Script objects | IBaseScriptObj |
| ”Get File', ”Check In Files”, 'Check Out Files' and ”Cancel Check Out Files” | IFileEventScriptObj |
| ”Incorporate Item”, ”Unincorporate Item”, ”Extend Actions Menu”, and ”Compliance Rollup on Object” | IBaseObjectScriptObj |
| ”Promotion Failure for Workflow” | IPromotionFailureScriptObj |
| ”Purge Version File Folder” | IPurgeFileScriptObj |
| ”Reminder for Workflow” | IReminderScriptObj |
| ”Save As Object” | ISaveAsScriptObj |
| ”Transfer Authority” | ITransferAuthorityScriptObj |
| ”Update Table” and ”Update Relationship” | IUpdateTableScriptObj |
| ”Update Title Block” | IUpdateTitleBlockScriptObj |
|
Note: In a Script PX, you can invoke any SDK or Java call. You can also access any third party Java or Groovy Libraries if they are deployed in the SDK extensions directory. |
Information provided in this section uses the Event Information objects and Event Script Objects to develop PX Handlers for Event-related actions, for example, general object actions such as Create Object, Delete Object; Workflow actions such as Change Status for Workflow.
Descriptions and samples for Event Information objects and Event Script objects appear in the following paragraphs. Other information includes code samples using these objects and guidelines to ensure proper handling of special instances of Events in Agile PLM.
All Event Information objects use the Base Event Information objects that. are Java interfaces. See the illustration in "Event Information Objects."
The Base Event Information object is IEventInfo.
Purpose and function - This is the interface for the Scheduled Event and Extended Tools Menu Event Information objects. In addition, IEvent Info is the inherited interface for all Event Information objects. It maintains information on Event type, Event trigger type, Event name, Event Subscriber name, Event Handler name, and user defined Maps.
User defined Maps serve as a place holder for any user defined data and provide a communication channel between subscribers. They are set in the Synchronous Java PXs and read by subsequent Synchronous Java PXs and Asynchronous Java PXs. Maps set inside Asynchronous PXs cannot be used by other Java PXs. If the Java PX fails, the Map is still accepted by Agile PLM and is passed to the next Java PX but all other changes in the Event Context objects are discarded.
IObjectEventInfo is the base event information object for object-related events.
Purpose and function - IEventInfo contains the Agile object for which the Event is triggered. Also, it is the interface for Incorporate Item, Unincorporate Item, Extend Actions Menu, and Compliance Rollup on object Event Information objects, and inherits from IEventInfo.
Inherited interface: IEventInfo
These examples show using IEventInfo and IObjectEventInfo.
Example 5-1 Using IEventInfo
private void testIEventInfo(IEventInfo req)throws APIException{
// getEventTriggerType() int evtTriggerType = req.getEventTriggerType();
// getEventName() String eventName = req.getEventName();
// getEventSubscriberName() String subscriberName = req.getEventSubscriberName();
// getEventHandlerHame() String handlerName = req.getEventHandlerName();
// setUserDefinedMap() Map map = new HashMap(); map.put("METHOD", "setUserDefinedMap()"); req.setUserDefinedMap(map);
// getUserDefinedMap() Map map2 = new HashMap(); map2 = req.getUserDefinedMap(); String mapValue = map2.get("METHOD").toString();
}
Example 5-2 Call made by IObjectEventInfo
private void testIObjectEventInfo(IEventInfo req)throws APIException{
String objNumber = ""; IObjectEventInfo info = (IObjectEventInfo)req; // getDataObject() IDataObject obj = info.getDataObject(); if (obj==null) objNumber = "NULL"; else objNumber = obj.getName();}
Base Event Script object is IBaseScriptObj.
Purpose and function - This is the interface for the Scheduled Event and Extend Tools Menu Event Script objects. IBaseScriptObj is the inherited interface for all Event Script objects. IBaseScriptObj maintains information on Event type, Event trigger type, Event name, Event Subscriber name, Event Handler name, and User Defined Maps.
IBaseObjectScriptObj is the base event information object for object-related events.
|
Note: This interface provides a Script method for sending Agile PLM Notifications. |
Purpose and function - IBaseObjectScriptObj contains the Agile object for which the Event is triggered. Also, it is the interface for Incorporate Item, Unincorporate Item, Extend Actions Menu, and Compliance Rollup on object Event Information objects and inherits from IBaseScriptObj.
Inherited interface: IBaseScriptObj
The following examples use IBaseScriptObj and IBaseObjectScriptObj.
Example 5-3 Using IBaseScriptObj
This example opens the SDK session and retrieves information pertaining to the Event.
void invokeScript(IBaseScriptObj obj){
// getEventType() int evttype = obj.getEventType();
// getEventTriggerType() int evtTriggerType = obj.getEventTriggerType();
// getEventName() String eventName = obj.getEventName();
// getEventSubscriberName() String subscriberName = obj.getEventSubscriberName();
// getEventHandlerHame() String handlerName = obj.getEventHandlerName();
//logMonitor () obj.logMonitor("Status is Passed");
//getAgileSDKSession() IAgileSession session = obj.getAgileSDKSession();
//getPXEventInfo () IEventInfo req = obj.getPXEventInfo();
//sendNotification() obj.sendNotification("Test", true, [ "admin"],
" passed from BaseScriptObj" + eventName);
// setUserDefinedMap()
obj.setUserDefinedMap
( [ 'Agile 93' : 'PLM Product', 'Scripting':'Is a Fun Tool']);
// getUserDefinedMap() Map myMap = obj.getUserDefinedMap ();
}
Example 5-4, "Using IBaseObjectScriptObject" retrieves Class ID and object number and sets the P1, P2, and P3 attribute values of the object.
(IBaseObjectScriptObj obj){
String objNumber = "";
//Disable all the warning exceptions raised obj.disableAllWarnings();
//get class ID int classID = obj.getClassId();
//get object number objNumber = obj.getObjectNumber();
//set attributes obj.setValueByAttId(CommonConstants.ATT_PAGE_TWO_TEXT01,"Text Value");
// get attribute value obj.getValueByAttId(CommonConstants.ATT_PAGE_TWO_TEXT01);
//log information to handler monitor
obj.logMonitor
("Object Number:" + objNumber); obj.logMonitor("Class Id :" + classID);
}
General Object actions are actions such as Create, Delete, Save As, and Update Title block. Information objects and Script Event objects for these Events are grouped and described according to their inherited interfaces.
The following paragraphs document the applicable methods and procedures.
The Information object for this Event is ICreateEventInfo.
Purpose and function - ICreateEventInfo retrieves the number and Subclass identifier of the requested new object. It can also overwrite the number and Subclass set by the clients.
Inherited interfaces - IUpdateEventInfo, IObjectEventInfo, IEventInfo. The IUpdateEventInfo retrieves the Array of Dirty attributes that users can overwrite, or set with new attributes and values.
The following examples show using ICreateEventInfo and IUpdateEventInfo
Example 5-5 Using ICreateEventInfo
private void testICreateEventInfo(IAgileSession session, IEventInfo req)
throws APIException { ICreateEventInfo info = (ICreateEventInfo)req; String number = ""; Integer subclass = null; String newNumber = getNewNumber(info);
Integer newSubclassId = getNewSubclassId(session, req); Integer newSubclass = null;
// getNewNumber() number = info.getNewNumber();
// getNewSubclassId() subclass = info.getNewSubclassId()
// setNewNumber() info.setNewNumber(newNumber);
// setNewSubclassId() info.setNewSubclassId(newSubclassId); newSubclass = info.getNewSubclassId();}
Example 5-6 Using IUpdateEventInfo
private void testIUpdateEventInfo(IAgileSession session, IEventInfo
req) throws Exception {
// Interface methods IUpdateEventInfo info = (IUpdateEventInfo)req;
//getCells() IEventDirtyCell[] cells = info.getCells();
// getAttributeIds() Integer[] attrs = info.getAttributeIds();
// setCell() and Get class specific P1 attribute Integer p1attrId = getP1Attribute(session, info);
// Override client value info.setCell(p1attrId, "set desc from CO");
// Add new Dirty value info.setCeldirtyl(CommonConstants.ATT_PAGE_TWO_TEXT02, "setCell()"); String value2 = info.getValue(CommonConstants.ATT_PAGE_TWO_TEXT02).toString();
// setCell() one from each attribute type * Date: Page Two.Date01 * Text: already cover * MultiText: Page Three.MultiText10 * List: Page Two.List01 * MultiList: Page Three.MultiList01 * Numeric: Page Two.Numeric 01 * Money: Page Three.Money01*/
Integer subClassId = getSubclassId(info); IAttribute attr1 = session.getAdminInstance().getAgileClass
(subClassId).getAttribute(CommonConstants.ATT_PAGE_TWO_LIST01);
IAttribute attr2 = session.getAdminInstance().getAgileClass(subClassId).getAttribute
(CommonConstants.ATT_PAGE_THREE_MULTILIST01);
IAgileList list1 = (IAgileList)attr1.getAvailableValues(); list1.setSelection(new Object[]{"b"}); IAgileList list2 = null; if (attr2!=null){ list2 = (IAgileList)attr2.getAvailableValues(); list2.setSelection(new Object[]{"a", "b", "e"}); } SimpleDateFormat df = new SimpleDateFormat("MM/dd/yyyy"); String d = "1/31/2009"; Date date = df.parse(d); info.setCell(CommonConstants.ATT_PAGE_TWO_DATE01, date); String multitext = "set multitext field in CO"; info.setCell(CommonConstants.ATT_PAGE_TWO_LIST01, list1); info.setCell(CommonConstants.ATT_PAGE_TWO_LIST02, list1);
// To test IEventDirtyCell info.setCell(CommonConstants.ATT_PAGE_TWO_NUMERIC01, 888.66); if (attr2!=null){ info.setCell(CommonConstants.ATT_PAGE_THREE_MULTITEXT10, multitext); info.setCell(CommonConstants.ATT_PAGE_THREE_MULTILIST01, list2); }
Money money = new Money (new Integer(100), "USD");
// removeCell()
info.removeCell(CommonConstants.ATT_PAGE_THREE_TEXT01);
}
The Information object for this Event is IUpdateTitleBlockEventInfo.
Purpose and function - IUpdateTitleBlockEventInfo is the interface for Update Title Block Event information object. Checks whether this is a redline update or undo-redline update on the Title Block of IItem object which has originated from the Affected Items table of the Change object
Inherited interfaces - IUpdateEventInfo, IObjectEventInfo, IEventInfo
The Information object for this Event is ISaveAsEventInfo.
Purpose and function - ISaveAsEventInfo performs the following tasks:
Retrieves the number and Subclass of the newly saved objectOverwrites the number and Subclass that are set by PLM clients
Inherited interfaces - IUpdateEventInfo, IObjectEventInfo, IEventInfo
The Information object for this Event is IDeleteEventInfo.
Purpose and function - IDeleteEventInfo is the interface for Delete Event information object. It performs the following tasks:
Retrieves the number and Subclass of the newly saved objectOverwrites the number and Subclass that are set by PLM clients
Inherited interfaces -IObjectEventInfo, IEventInfo
The Information object for this Event is IExportEventInfo.
Purpose and function - IExportEventInfo performs the following tasks:
Retrieves the format of the export file
Returns the array of objects that are exported
Returns the tables for exporting the object
Inherited interfaces - IEventInfo
This section lists and describes Script PXs that support General Action Objects
The Script Event object for this Event is ICreateScriptObj.
Purpose and function - The same as ICreateScriptObj
Inherited interfaces - IUpdateScriptObj, IBaseObjectScriptObj, IBaseScriptObj
Purpose and function of the inherited interfaces - The same as IUpdateEventInfo, IObjectEventInfo and IEventInfo
The following examples use ICreateScriptObj and IUpdateScriptObj.
Example 5-7 Using ICreateScriptObj
// In this example, ICreateScriptObj modifies the number and class ID of the new object.
void testICreateScriptObj(IBaseScriptObj obj){
String origNumber = ""; String newNumber = ""; int newSubclassId = ItemConstants.CLASS_DOCUMENT ;
// new subclass ID of choice int newSubclass ; int subclass;
// getNewNumber() origNumber = obj.getNewNumber(); newNumber = origNumber +"new";
// setNewNumber() obj.setNewNumber(newNumber); newNumber = obj.getNewNumber();
// getNewSubclassId() subclass = obj.getNewSubclassId();
// setNewSubclassId() obj.setNewSubclassId(newSubclassId); newSubclass = obj.getNewSubclassId();
// log new object number and new subclass ID in to handler monitor obj.logMonitor("new object number is:" + newNumber); obj.logMonitor("new subclass ID is:" + newSubclass);}
In Example 5-8, "Using IUpdateScriptObj"the IUpdateScriptObj method Gets the ID and value of Dirty attributes. It then sets the Dirty attribute values obtained from the context object, and removes the value of Dirty attributes.
Example 5-8 Using IUpdateScriptObj
void testIUpdateScriptObj(IBaseScriptObj obj){ String dirtyAttr = ""; String dirtyValue = "";
// get Attribute Ids int[] attrs = obj.getAttrIds(); attrs.each {attr->
// get Attribute value dirtyAttr = obj.getDirtyAttr(attr);
// log attribute Id and value in to handler monitor
obj.logMonitor("Dirty Attr Id :" + attr); obj.logMonitor(" dirty Attr value:" + dirtyAttr); }
// Overwrite client value obj.setDirtyAttrValue(CommonConstants.ATT_PAGE_TWO_TEXT02,
"set text value from CO");
//Remove Dirty Attribute value
obj.removeDirtyAttr(CommonConstants.ATT_PAGE_TWO_TEXT02);
// get dirty attribute value after removing value from CO dirtyValue = obj.getDirtyAttrValue(CommonConstants.ATT_PAGE_TWO_TEXT02);
}
The Script Event object for this Event is IUpdateTitleBlockScriptObj.
Purpose and function - IUpdateTitleBlockScriptObj checks whether this is a redline update or undo-redline update on the Title Block of the IItem object which has originated from the Affected Items table of Change object
Inherited interfaces - IUpdateScriptObj, IBaseObjectScriptObj, IBaseScriptObj
Script Event object for this Event is ISaveAsScriptObj.
Purpose and function - ISaveAsScriptObj retrieves the name or number for the new object.
Inherited interfaces - ISaveAsScriptObj, IBaseObjectScriptObj, IBaseScriptObj
The Information object for this Event is IDeleteScriptObj.
Purpose and function - IDeleteScriptObj deletes the Event Script object.
Inherited interfaces - IBaseObjectScriptObj, IBaseScriptObj
Script Event object for this Event is IExportScriptObj.
Purpose and function - IExportScriptObj retrieves the format for the export object.
Inherited interfaces - IExportScriptObj
Example 5-9, "Using IExportScriptObj" retrieves information about the object that is exported.
Example 5-9 Using IExportScriptObj
void testIExportScriptObj(IBaseScriptObj obj){
int format; int[] selectedTables; String objects ="";
String user = "";String objectNumber ="P00002" ; // the object number being exported
// get current user user = obj.getCurrentUser();
// get file format for the export. format = obj.getExtractedFormat();
// get list of Object Names being exported objects = obj.getExtractedObjects();
// get tables selected for export selectedTables = obj.getSelectedTables(objectNumber);
// log current user, extracted format, object names and tables which
exported into handler monitor obj.logMonitor("current user is:" + user); obj.logMonitor("file format is:" + format); obj.logMonitor("Object Names are:" + objects); obj.logMonitor("Selected Tables are:" + selectedTables);}
These actions include updating the supported object tables for specific business objects.
This section lists and describes the applicable Java PXs.
The Information object for this Event is IUpdateTableEventInfo.
Purpose and function - IUpdateTableEventInfo is the interface for Update Table and Update Relationship. It retrieves the Dirty table for the affected object.
Inherited interfaces - IObjectEventInfo and IEventInfo.
Related interfaces:
IEventDirtyFile is the interface for a Dirty file associated with IEventDirtyRowFileUpdate or IFileEventInfo. It represents a single row in a file table and retrieves the checkout date of the Dirty file.
IEventDirtyTable is the interface for a Dirty table associated with IUpdateTableEventInfo or IEventDirtyRow. The Dirty table contains a collection of modified rows. It provides access to transient table information for modified tables.
IEventDirtyCell is the interface for a Dirty cell associated with IEventDirtyRowUpdate or IUpdateEventInfo. Represents a single cell in a row. It returns the attribute identifier corresponding to this Dirty cell.
IEventDirtyRowFileUpdate retrieves the Dirty file. It is the interface for a Dirty row used to perform Dirty Row Actions (Add file, Replace file).
IEventDirtyRowUpdate retrieves the Dirty row for which the update occurs. This interface is used by the update on all tables except the attachment table.
|
Note: You can find information on "Dirty" objects in the SDK samples Documentation folder. To access this folder, see the Note in "Client-Side Components." |
These examples use IEventDirtyTable and IEventDirtyRowUpdate on an Item BOM table.
Example 5-10 Using IEventDirtyTable
private void testIEventDirtyTable(IAgileSession session,
IEventDirtyTable table, IDataObject obj, int evtTriggerType) throws Exception {
//Get TableId()
String tableName = getTableName(obj, table);
// size() int size = table.size(); //iterator()
Iterator it = table.iterator(); while (it.hasNext()){ IEventDirtyRow row = (IEventDirtyRow)it.next(); if(row.getAction()!=
EventConstants.DIRTY_ROW_ACTION_ADD_FILE&&row.getAction()!=
EventConstants.DIRTY_ROW_ACTION_REPLACE_FILE)
//user defined method
testIEventDirtyRowUpdateCommon(session, row, obj, evtTriggerType); else testIEventDirtyRowFileUpdate(row);// user defined method }}
Example 5-11 IEventDirtyRowUpdate on Item BOM table
private void testIEventDirtyRowUpdate_ItemBOM_Update
(IEventDirtyRowUpdate row, IDataObject obj) throws Exception {
// user defined method
/* setCell() - Override * List01 ==> c * MultiText30 ==> setCell() on update * Text01 ==> setCell()on update * Numeric01 ==> 888.66 * BOM Notes ==> setCell() from CO*/
//List01 IAttribute attrList = obj.getAgileClass().getAttribute(ItemConstants.ATT_BOM_BOM_LIST01); IAgileList list = (IAgileList)attrList.getAvailableValues(); list.setSelection(new Object[]{"c"}); row.setCell(ItemConstants.ATT_BOM_BOM_LIST01, list);
//MultiText30 row.setCell(ItemConstants.ATT_BOM_BOM_MULTITEXT30, "setCell() MT30 update");
//Text01 row.setCell(ItemConstants.ATT_BOM_BOM_TEXT01, "setCell() T01 update"); //Numeric01 row.setCell(ItemConstants.ATT_BOM_BOM_NUMERIC01, 888.66); //BOM Notes row.setCell(ItemConstants.ATT_BOM_BOM_NOTES, "setCell() Notes update") /*
* setCell() - New * List02 ==> a * Text02 ==> setCell() on update */ // List02 row.setCell(ItemConstants.ATT_BOM_BOM_LIST02, list);
//Text02 row.setCell(ItemConstants.ATT_BOM_BOM_TEXT02, "setCell() T02 update"); // Qty row.setCell(ItemConstants.ATT_BOM_QTY, new Integer(2));
//removeCell() ==> Date01 & Find Num row.removeCell(ItemConstants.ATT_BOM_BOM_DATE01); row.removeCell(ItemConstants.ATT_BOM_FIND_NUM);
// getCell() EventDirtyCell cell = row.getCell(ItemConstants.ATT_BOM_BOM_LIST02) }
This section lists and describes the Script PXs that support Table and Relationships action.
The Script Event object for this Event is IUpdateTableScriptObj.
Purpose and function - IUpdateTableScriptObj is the interface for Update Table and Update Relationship. It retrieves the dirty table for the affected object.
Inherited interfaces - IUpdateTableScriptObj. See "Base Event Script Objects - Script PX."
Related interfaces
IEventDirtyRow is the base interface for a dirty row associated with IUpdateTableScriptObj. It represents a single row in a table. There is an action associated with the row.
IEventDirtyRowFileUpdate retrieves the dirty file row. It is the interface for a dirty file row used to perform Dirty File Row Actions (Add file, Replace file).
IEventDirtyRowUpdate retrieves the Dirty row. It is the interface for a Dirty row used to perform Dirty Row Actions (Add, Delete, Update, Redline Add, Redline Delete, Redline Update, Undo Redline.)
IEventDirtyFile is the interface for a Dirty file associated with IEventDirtyRowFileUpdate or IFileEventInfo. It represents a single row in a file table and retrieves the checkout date of the Dirty file.
The following examples show using IEventDirtyTable and IEventDirtyRowUpdate on an Item BOM table.
Example 5-12 Using IEventDirtyTable
// IUpdateTableScriptObj: get table id and Dirty row ids void testIUpdateTableScriptObj(IBaseScriptObj obj){
//getTableId() int table_id= obj.getTableId(); obj.logMonitor("Table Id" + table_id);
// getDirtyRowIds() rowIDs =obj.getDirtyRowIds(); rowIDs.each{rID-> //loop through Dirty rows obj.logMonitor("rowID is " + rID);
//getDirtyRow() row = obj.getDirtyRow(rID);
// getAction action = row.getAction(); obj.logMonitor ("Action" + action); if ((action == EventConstants.DIRTY_ROW_ACTION_ADD_FILE) || (action
== EventConstants.DIRTY_ROW_ACTION_REPLACE_FILE)) testIEventDirtyRowFileUpdate(obj,row,rID); // user methodelse testIEventDirtyRowUpdate(obj,row,rID); // user method }
}
The following Item BOM table example gets the object number and action for a single row associated with IUpdateTableScriptObj.
Example 5-13 Using IEventDirtyRowUpdate
void testIEventDirtyRowUpdate
(IBaseScriptObj obj,IEventDirtyRow row, int rID) {
//getRowId()
int rid = row.getRowId();
// getObjectNumber()
int rnumber = row.getObjectNumber(); obj.logMonitor("row object" + rnumber);
// getDirtyRow
dirtyRow = obj.getDirtyRow(rID);
//from client, update following attributes in Bom table
// find number,Bom notes, Multi Text01,List01,date01, Text01, numeric0
//getDirtyAttrIds()
dirtyRow = obj.getDirtyRow(rID); dirtyAttrs = dirtyRow.getDirtyAttrIds(); def sort_attrs = dirtyAttrs as List;
//sort attribute Ids
sort_attrs.sort();
// getDirtyAttrValue() sort_attrs.each {dirtyAttr-> attrValue = dirtyRow.getDirtyAttrValue(dirtyAttr); obj.logMonitor('***'+"attribute value" +'=' + attrValue); }// array of vlues to overwrite attributes from Context object//[find number,Bom notes, Multi Text01,List01,date01, Text01, numeric01]set_dirty_value = ["5","Bom Note","Multi text 03","e","2009-01-30 08:00:00","Text 01","224466"];
//setDirtyAttrValue , overwrite attribute values int indexy =0; sort_attrs.each{att-> dirtyRow.setDirtyAttrValue(att , set_dirty_value[indexy++]); }
// getDirtyAttrValue() after overwrite in CO int indexB=0; sort_attrs.each {dirtyAttr-> attrValue2 = dirtyRow.getDirtyAttrValue(dirtyAttr); all_attrValue2[indexB++]= attrValue2; }// removetDirtyAttr() remove dirty attributes and rollback changes sort_attrs.each {dirtyAttr-> dirtyRow.removetDirtyAttr(dirtyAttr); }}
Variant Management events include:
Create Variant Instance
The event handler creates the derived Instance BOM.
Derive Variant Model Option BOM
The event handler creates the logical structure of the Instance BOM without actually creating new items or changing the BOM tab of an item.
Update Variant Configuration
The event handler adds or removes configuration options and runs propagations and pre-selections.
Validate Variant Configuration
The event handler checks the consistency of the Configuration Graph and the Model Option BOM.
Validate Variant Instance Selections
The event handler checks validation rules for the configuration, for example, minimum/maximum violations, or if an Option Class has enough valid child options.
Validate Variant Model Option BOM
The event handler checks validation rules on the Model Option BOM. For example, if the minimum quantity value is smaller/equal to the maximum quantity value, or if an Option Class has valid child options.
These events can only be triggered on Model part subtype. Once the event is enabled, it replaces the system behavior instead of extending it.
|
Note: You can download the Variant Management SPX and JPX default scripts from Oracle Agile PLM's Event and Web Services Samples website. For information to access this site, see the Note in "Client-Side Components." |
The information object for these Events is IVMEventObj:
Create Variant Instance
Derive Variant Model Option BOM
Update Variant Configuration
Validate Variant Configuration
Validate Variant Instance Selections
Validate Variant Model Option BOM
IVMEventObj is the interface for the Variant Management events information object. It provides access to the Configuration Graph, the Model Option BOM and the Instance BOM (if available).
|
Note: You can find more information on the purpose and function of these Events and when they are triggered, in the Agile PLM Administrator Guide and the chapter entitled "Configuring Variant Management" in Agile PLM Product Collaboration User Guide. |
Inherited interfaces - IObjectEventInfo, IEventInfoThe following example shows how to use IVMEventObj
private void testIVMEventObj(IVMEventObj req) {
IConfigurationGraph graph = req.getConfigurationGraph();
// get Model Option BOM
IModelOptionBOM mob = req.getModelOptionBOM();
// getting unique id of item that has been selected/deselected/modified
// by the user
IUniqueId currentId = req.getCurrentUniqueId();
IModelOptionBOMItem item = mob.findItem( currentId);
graph.selectOption( item );
}
The information object for these Events is IVMScriptObj:
Create Variant Instance
Derive Variant Model Option BOM
Update Variant Configuration
Validate Variant Configuration
Validate Variant Instance Selections
Validate Variant Model Option BOM
IVMScriptObj is the interface for the Variant Management events information object. It provides access to the Configuration Graph, the Model Option BOM and the Instance BOM (if available).
|
Note: You can find more information on the purpose and function of these Events and when they are triggered, in the Agile PLM Administrator Guide and the chapter entitled "Configuring Variant Management" in Agile PLM Product Collaboration User Guide. |
Inherited interfaces - IBaseObjectScriptObj, IBaseScriptObj
The following is a usage example of IVMScriptObj method.
{
// get configuration graph
IConfigurationGraph graph = obj.getConfigurationGraph();
// get Model Option BOM
IModelOptionBOM mob = obj.getModelOptionBOM();
for ( IConfigurationOption option in graph ) {
IModelOptionBOMItem mobItem = mob.findItem(
option.getUniqueId() );
if (option.getQuantity() > mobItem.getMaxQuantity()) {
obj.addErrorMessage( option, "Quantity must not be greater than max. quanity())
}
}
These are Workflow-related actions such as, Change Status for Workflow, Change Approvers or Observers for Workflow, and change the status of Product Cost Management's Sourcing Project.
This section lists and describes the Java PXs that support Workflow object actions.
The Information object for this Event is IWFChangeStatusEventInfo.
Purpose and function - IWFChangeStatusEventInfo retrieves changes in Workflow status of the object and assigned notifiers and checks whether the "auto-promote" flag is set or not set.
Inherited interfaces - IRoutingSlipEventInfo , IRoutableObjectEventInfo, IObjectEventInfo, IEventInfo
Inherited interfaces purpose and function:
IRoutingSlipEventInfo - Is the inherited interface for all Event Information objects that contain the Routing slip Object and provides methods to set/get approvers, observers, comments, and urgent flags
IRoutableObjectEventInfo - Is the inherited interface for all Event Information objects related to workflow actions and provides methods such as get/set approvers or observers
The following examples use IWFChangeStatusEventInfo, IRoutingSlipEventInfo and IRoutableObjectEventInfo.
Example 5-15 Using IWFChangeStatusEventInfo
private void testIWFChangeStatusEventInfo(IAgileSession session, IEventInfo req) throws APIException { IWFChangeStatusEventInfo info = (IWFChangeStatusEventInfo)req;
//getNotifiers() IDataObject[] notifiers = info.getNotifiers();
// isAutoPromote() boolean isAutoPromote = info.isAutoPromote();
// setNotifiers() IUser user = getUser(session, "yvonnec"); IUserGroup ug = getUserGroup(session, "SOA"); Collection col = new ArrayList(); col.add(user); col.add(ug); info.setNotifiers(col);
// getFromStatus() IStatus fromStatus = info.getFromStatus();
// getToStatus() IStatus toStatus = info.getToStatus();
}
Example 5-16 Using IRoutingSlipEventInfo
private void testIRoutingSlipEventInfo(IAgileSession session,
IEventInfo req) throws APIException {
IRoutingSlipEventInfo info = (IRoutingSlipEventInfo)req; Collection colAppvrs = new ArrayList(); Collection colObsvrs = new ArrayList(); Collection colNewAppvrs = new ArrayList(); Collection colNewObsvrs = new ArrayList(); String newComments = "Override in context object."; //getApprovers() IDataObject[] approvers = info.getApprovers(); String approverList = arrayToString(approvers); //getObservers() IDataObject[] observers = info.getObservers(); //getComments() String comments = info.getComments(); //isUrgent() boolean isUrgent = info.isUrgent(); //setApprovers() IUser user1 = getUser(session, "badriv"); IUser user2 = getUser(session, "albertl"); IUser user3 = getUser(session, "brucec"); IUserGroup ug1 = getUserGroup(session, "SOA"); info.setApprovers(colAppvrs); IDataObject[] newApprovers = info.getApprovers(); //setObservers() info.setObservers(colObsvrs); IDataObject[] newObservers = info.getObservers(); //setComments()info.setComments(newComments);String latestComments = info.getComments(); //setUrgent() boolean newUrgent = getOppositeBoolean(isUrgent); info.setUrgent(newUrgent); boolean latestUrgent = info.isUrgent();}
Example 5-17 Using IRoutableObjectEventInfo
private void testIRoutableObjectEventInfo(IEventInfo req) throws APIException {
IRoutableObjectEventInfo info = (IRoutableObjectEventInfo)req;
//getWorkFlow()
IWorkflow wf = info.getWorkFlow();
}
The Information object for this Event is ISignOffEventInfo.
Purpose and function - ISignOffEventInfo is the interface for Approve for Workflow and Reject for Workflow. It returns and overwrites information about status, approvers (users), approver groups, and checks the status of the signoff flag.
Inherited interfaces - IRoutableObjectCommentEventInfo, IRoutableObjectEventInfo, IObjectEventInfo, IEventInfo
Inherited interfaces purpose and function - IRoutableObjectCommentEventInfo is the interface for Comment for Workflow. It retrieves and overwrites Comment type data provided for Workflow, Approve for Workflow, and Reject for Workflow Events.
The Information object for this Event is IEscalationEventInfo.
Purpose and function - IEscalationEventInfo retrieves the following information about the Escalation for Workflow Event:
Sign-off user, escalated to users, escalation period, and status of the workflow
Inherited interfaces - IRoutableObjectEventInfo, IObjectEventInfo, IEventInfo
Inherited interfaces purpose and function - See "Approve for Workflow."
The Information object for this Event is IReminderEventInfo.
Purpose and function - IReminderEventInfo returns notifiers assigned to the Workflow reminder.
Inherited interfaces - IRoutableObjectEventInfo, IObjectEventInfo, IEventInfo
The Information object for this Event is IAuditStatusEventInfo.
Purpose and function - IAuditStatusEventInfo retrieves the type of Workflow Audit Action that is performed.
Inherited interfaces - IAuditResultEventInfo, IRoutableObjectEventInfo, IObjectEventInfo, IEventInfo
Inherited interfaces purpose and function - IAuditResultEventInfo is the interface for Audit for Workflow and Promotion Failure for Workflow. It retrieves error messages for the audit or promotion failure.
The Information object for this Event is IRoutableObjectCommentEventInfo. See "Approve for Workflow."
The Information object for this Event is IChangeAppObserverEventInfo.
Purpose and function - IChangeAppObserverEventInfo retrieves the action type, status, and the applied to status of the Change Approvers or Observers for the Workflow Event plus the change action by the approver or observer on the Workflow state.
Inherited interfaces - IRoutingSlipEventInfo
This section lists and describes the Script PXs that support Workflow object actions.
The Information object for this Event is IChangeStatusScriptObj.
Purpose and function - IChangeStatusScriptObj retrieves changes in the Workflow status of the object, the assigned notifiers, and checks whether the "auto-promote" flag is set or not set.
Inherited interfaces - IRoutingSlipScriptObj , IRoutableScriptObj, IBaseObjectScriptObj, IBaseScriptObj
Inherited interfaces purpose and function:
IRoutingSlipScriptObj - Inherited interface for all Event Script objects that contain the Routing slip Object
IRoutableScriptObj - Inherited interface for all Event Script objects related to workflow actions
The following examples use the IChangeStatusScriptObj, IRoutingSlipScriptObj, and IRoutableObjectScriptObj scripts.
IChangeStatusScriptObj: Change Status for Workflow Event script object.
void testIChangeStatusScriptObj (IChangeStatusScriptObj obj)
{
// getFromStatus() String current_status = obj.getFromStatus();
// getToStatus() String next_status = obj.getToStatus();
// getNotifiers() String notifiers =obj.getNotifiers();
// setNotifiers() obj.setNotifiers(["admin", "demo1","weiz", "demo5"]);
// isAutoPromote() boolean auto = obj.isAutoPromote();
}
The Information object for this Event is ISignOffScriptObj.
Purpose and function - ISignOffScriptObj is the interface for Approve for Workflow and Reject for Workflow. It returns information about status, approvers (users), approver groups, and checks the status of the signoff flag.
Inherited interfaces - IRoutableObjectCommentScriptObj, IRoutableScriptObj, IBaseObjectScriptObj, IBaseScriptObj
Purpose and function of Inherited interfaces - IRoutableObjectCommentScriptObj is the Interface for Comment for Workflow. It retrieves comments provided for the Routable object.
The Information object for this Event is IEscalationScriptObj.
Purpose and function - IEscalationScriptObj retrieves names of users to whom the Workflow is escalated to.
Inherited interfaces - IRoutableScriptObj, IBaseObjectScriptObj, IBaseScriptObj
purpose and function of Inherited interfaces - See "Approve for Workflow."
The Information object for this Event is IReminderScriptObj.
Purpose and function - IReminderScriptObj returns the notifiers assigned to the reminder period and Workflow reminder.
Inherited interfaces - IRoutableScriptObj, IBaseObjectScriptObj, IBaseScriptObj
The Information object for this Event is IAuditStatusScriptObj.
Purpose and function - IReminderScriptObj retrieves the type of Workflow Audit Action that is performed.
Inherited interfaces - IAuditResultScriptObj, IRoutableScriptObj, IObjectScriptObj, IBaseScriptObj
Inherited interfaces purpose and function - IAuditResultScriptObj is the interface for Audit for Workflow and Promotion Failure for Workflow. It retrieves error or warning messages and Workflow status information for the audit or promotion failure.
The Information object for this Event is IRoutableObjectCommentScriptObj. See "Approve for Workflow."
The Information object for this Event is IChangeAppObserverScriptObj.
Purpose and function - IChangeAppObserverScriptObj retrieves the action type, status, and the applied to status of the Change Approvers or Observers for the Workflow Event and the change action by the approver or observer on the Workflow state.
Inherited interfaces - IRoutingSlipScriptObj
These actions support incorporating and unincorprating the Item object in PLM's Production Collaboration solution and change status for Sourcing projects.
The related actions are listed and described below.
The Information object for this Event is IObjectEventInfo.
The Information object for this Event is ISourcingObjectChangeStatusEventInfo.
Purpose and function - ISourcingObjectChangeStatusEventInfo retrieves the type of action that is performed on the Sourcing object.
Inherited interfaces - IObjectEventInfo and IEventInfo
The following paragraphs describe the Script PX that supports Specific Object-Based Actions.
The Script Event object for this Event is IBaseObjectScriptObj.
The Information object for this Event is ISourcingObjectChangeStatusScriptObj.
Purpose and function - ISourcingObjectChangeStatusScriptObj retrieves the type of action that is performed on the Sourcing object.
Inherited interfaces - IBaseObjectScriptObj and IBaseScriptObj
These are the file-related actions such as check out file, check in file, and purging version files.
The following paragraphs describe the Java PX that supports Files and Attachments objects actions.
The Information object for this Event is IPurgeFileEventInfo.
Purpose and function - IPurgeFileEventInfo retrieves the version for the purged file.
Inherited interfaces - IObjectEventInfo and IEventInfo
The Information object for this Event is IIncorporateFileEventInfo.
Purpose and function - IIncorporateFileEventInfo retrieves the affected File Folders
Inherited interfaces - IObjectEventInfo and IEventInfo
The following paragraphs describe the Script PX that supports Files and Attachments objects actions.
The Event Script object for these Events is IFileEventScriptObj.
Purpose and function - IObjectEventInfo retrieves the Dirty files for the selected file attachments.
Inherited interfaces - IBaseObjectScriptObj and IBaseScriptObj
The Event Script object for this Event is IPurgeFileScriptObj.
Purpose and function - IPurgeFileScriptObj retrieves the version for the purged file
Inherited interfaces - IBaseObjectScriptObj and IBaseScriptObj
The following example shows using IFileEventScriptObj.
Example 5-20 Using IFileEventScriptObj
// FileEventScriptObj: get file for file actions related events
void testIFileEventScriptObj(IBaseScriptObj obj,IEventDirtyRow row){
// getFile() file = row.getFile(); testIEventDirtyFile(obj,file);}
Example 5-21 Using IEventDirtyFile
// IEventDirtyFile: get file information for Dirty file associated with
// IEventDirtyRowFileUpdate
void testIEventDirtyFile(IBaseScriptObj obj,IEventDirtyfile file){
// getFilename() String file_name = file.getFilename();
// getSize() int file_size = file.getSize();
// getType() file_type = file.getType();
// getFileFolderNumber() file_folder_num = file.getFileFolderNumber();
// getFileFolderVersionNumber() file_folder_ver = file.getFileFolderVersionNumber();
//getCheckoutUser() user = file.getCheckoutUser();
// getCheckoutDate()date = file.getCheckoutDate(); obj.logMonitor("file name is:" + file_name); obj.logMonitor("file size is:" + file_size); obj.logMonitor("file type is:" + file_type); obj.logMonitor("file folder number is:" + file_folder_num); obj.logMonitor("file folder version number is:" + file_folder_ver); obj.logMonitor("checkout user is:" + user); obj.logMonitor("checkout date is:" + date);
}
This action supports checking compliance of PG&C objects.
The following paragraphs describe the Java PXs that support Product Governance and Compliance actions.
The Information object for this Event is IObjectEventInfo. This interface and the applicable inherited interfaces are documented in "General Object Actions - Java PX."
The following paragraphs describe the Script PX that supports Product Governance and Compliance actions
The Information object for this Event is IBaseScriptObj. This interface and the applicable inherited interfaces are documented in "General Object Actions - Script PX."
These are the file-related actions such as check out file, check in file, and purging version files.
The following paragraphs describe the Java PXs that support the miscellaneous object actions
The Information object for this Event is ITransferAuthorityEventInfo.
Purpose and function - ITransferAuthorityEventInfo contains the data belonging to Transfer Authority action and retrieves and overwrites data set by the PLM client for the Transfer Authority action.
Inherited interfaces - IExportEventInfo.
Events can be invoked from Agile PLM clients' Extend Actions Menu, Extend Tools Menu, and Scheduled Event described below.
The following paragraphs list and describe the Java PX that support Event integration points in PLM Clients.
The Information object for this Event is IObjectEventInfo and User Role is Required to view the PX. This interface and the applicable inherited interfaces are documented in "General Object Actions - Java PX."
The Information object for this Event is IEventInfo and User Role is Required to view the PX. This interface and the applicable inherited interfaces are documented in "General Object Actions - Java PX."
The Information object for this Event is IEventInfo. This interface and the applicable inherited interfaces are documented in "General Object Actions - Java PX."
The following paragraphs list and describe the Script PXs that support Event integration points in PLM Clients.
The Information object for this Event is IBaseScriptObj. This interface and the applicable inherited interfaces are documented in "General Object Actions - Script PX."
The Information object for this Event is IBaseObjectScriptObj. This interface and the applicable inherited interfaces are documented in "General Object Actions - Script PX."
The Information object for this Event is IBaseScriptObj. This interface and the applicable inherited interfaces are documented in "General Object Actions - Script PX."
These comments and recommendations are intended to ensure the proper development and implementation of your Java PXs and Script PXs. They include:
Information that you need from the Agile PLM Administrator to code the handler and information that you must convey to the Administrator to configure and implement the Event
Information to ensure proper handling of Events
Information to test your PXs
The Agile PLM Administrator will convey the necessary information to determine the Event type, execution mode and trigger type. Once you have developed the Java PX or Script PX handlers, you must inform the Administrator about the Event subscriber. This information includes Event type, execution mode, trigger type, order, and applicable error handling rule.
In addition to information about Event subscriber, the Administrator needs the following specific information to configure the Event Handler.
Java PX Handlers - Java PXs are deployed on the server. For procedures, see "Packaging and Deploying a Custom Autonumber Source." Once deployed, the Administrator locates it in Java Client by selecting Admin > Settings > System Settings > Event Management > Event Handlers > New. The Create Event Handler dialog box appears. In Event Handler Type field select > Java PX > Event Action. The Administrator needs to know the name that appears in the Event Action field, to configure the Handler.
Script PX Handlers - The script PX code is a text file. You must send the script text file to the PLM Administrator. The Administrator will then paste it in the Script field of the Create Event Handler dialog and proceed to configure the Subscriber. This field is accessed from Java Client by selecting Administrator > Event Management > Event Handlers > Create Event Handler > Script PX > Script.
If the Agile PLM Administrator uses your Handlers to configure the Event Subscriber, you should coordinate testing the PXs with the Administrator. On the other hand, if you do the configurations, then use the following information for this purpose.
Invoke the new Java PX or Script PX to ensure the action specified in the Handler (code) executes properly.
If the PX is configured to be invoked by a user action from the Tools menu, you can test it in Web Client or Java Client as follows:
In Web Client tool bar select the Tools and Settings button and then <Event_name>.
In Java Client tool bar select the Process Extensions button or Tools > Process Extensions ><Event_name>.
Use the following guidelines when developing Handlers to ensure proper triggering of the special instances of these Event types.
The following paragraphs describe the Java and Script PXs that ensure proper triggering of general object Events, such as Create and SaveAs Events.
Web Client and Java Client behavior - This action will trigger one Create Object Event (or SaveAs Event) and its Context object will contain all Dirty attributes for Page 1, Page 2 and Page 3.
SDK behavior - This action will trigger one Create object Event (or SaveAs Event). In addition, depending on table attributes that are updated (Page 1, Page 2 and Page 3), one to three Update Title Block Events are triggered. The context object will contain all Dirty attributes belonging to that table.
Web Client, Java Client, and SDK behavior - Depending on table attributes that are updated (Page 1, Page 2 and Page 3), one to three Update Title Block Events are triggered, one for each table. The context object will contain all Dirty attributes belonging to that table.
When you add, modify, or delete more than one row, this action has the following Event triggering behavior:
One Event is triggered and the Context object will contain all applicable rows. The only exceptions are in Java Client:
Relationships Table- One Event is triggered for each applicable row and the Context Object will contain the applicable row
Attachment Table - For Update and Delete Actions, one Event is triggered for each applicable row and the Context Object will contain the applicable row
The following paragraphs list and describe the Java and Script PXs that support Workflow-related actions.
The following actions trigger this Event:
Failure of Change Status triggered through Relationship
Autopromotion Failure - Autopromotion Failure is invoked by the following object actions when autopromotion conditions are not met after the completion of these actions. In addition, each triggered Event is tracked in the object History.
Change Status
Sign off the change
Remove Approvers
Update Cover Page, Page 2, and Page 3 attributes
Edit Affected Item Table, Relationship, File Attachment Tab
Cancel checkout attachment
Checkin attachment
ATO creation is enabled when ECO status is changed from Pending to Submitted. The sequence of Events that are triggered when the ATO is created is:
Pre and Post Event Subscribers are created for:
ECO Change status
ATO Create
ATO Change Status
An ECO is created
Workflow is assigned and status is changed to submitted
The following paragraphs list and describe when File and Attachment Event are triggered.
This action will trigger the following Events:
Check In File Event on File Folder objects - This Event is triggered when the Check In file action is performed on File Folder objects.
Check In File Event and Update Table Event on Business objects - These Events are triggered when the Check In file action is performed on Business objects.
|
Note: Update Table Event on Business objects is triggered after Check In File Event is triggered. Also, The Event is only triggered if the folder version of the attachment is not set to [LATEST]. In Web Client one Event is triggered for all selected rows. In Java Client, one Event is triggered for each selected row. |
This action will trigger the following Events:
Check Out Files Event and Get File Event on File Folder objects - These Events are triggered when the Check Out file action is performed on File Folder objects
Check Out Files Event and Get File Event on Business objects - These Events are triggered when the Check Out file action is performed on Business objects in Java Client,
If Download files in one ZIP file option is selected, one Get File Event is triggered and each row triggers a Checkout Event
If Download files in one ZIP file option is not selected, each row triggers one checkout Event and each file triggers a Get File event
|
Note: In Web Client one Event is triggered for all selected rows. In Java Client, one Event is triggered for each selected row. |
This action will trigger the following Events:
Cancel Check Out Files Event on File Folder objects - This Event is triggered when the Cancel Check Out file action is performed on File Folder objects
Cancel Check Out Files Event on Business objects - This Event is triggered when the Cancel Check Out file action is performed on Business objects
|
Note: In Web Client one Event is triggered for all selected rows. In Java Client, one Event is triggered for each selected row. |
The following actions trigger this Event is:
Clicking the Get button on the Attachments table of Business objects or Files table of File Folder objects
Clicking Filename on the Attachments table of the object
|
Note: If the file is viewable, Agile Viewer is launched and no event will be triggered. |
Check Out file action
|
Note: In Java Client, if users choose to download files individually instead of downloading the .ZIP file, one Event is triggered for each selected File. |
