| Agile Product Lifecycle Management ACS User Guide Release 9.3.4 E52167-02 |
|
 Previous |
 Next |
This chapter includes the following:
Overview
About Agile Content Service
How Agile Content Service Works
Setting Up Agile Content Service
Workflows for Transfer Orders
Tracking Published Data
This chapter provides information and procedures to configure the Agile Content Service™ (ACS) to generate product records for applications and users, both internally and across the global manufacturing network.
ACS is an event-driven XML-based publishing service that makes the product record available to a wide variety of business applications and users, both internally and across the global manufacturing network. In addition to allowing employees and supply chain partners to publish the product record on demand, you can configure the ACS to automatically publish the Item Master, BOM, and AML changes during any phase of the product lifecycle to multiple destinations, ensuring that everyone is working with up-to-the-minute information.
Every time ACS publishes product content, it produces a transfer order that keeps track of what, where, and when product content is transferred. ACS allows for destination-specific content, ensuring that external entities receive only the information to which they should have access. You can configure the roles and privilege masks to ensure the right information is sent.
Agile PLM users can publish product content in real time with a content transfer order (CTO) or set up subscribers to automatically create automated transfer orders (ATO) based on a schedule or triggered by a workflow status change. ACS is easily configured and can support transfers to multiple destinations and transfer protocols, including a file, HTTP, HTTPS, FTP, JMS, or another Agile PLM system.
Before publishing content, ACS needs to know exactly what content must be transferred also when it goes, where it goes, and a few other factors.
ACS consists of the following components:
Destinations (Where)
Destinations define where to publish product content. Agile PLM provides a file, FTP, HTTP(S), JMS queue, and Agile system as destination types. Users can publish product content to any number of destinations across these destination types.
A file destination is useful when users publish to internal systems. FTP and HTTP(S) destinations are useful when users publish to external systems. A JMS queue destination Type is useful when users publish to an EAI system. An Agile destination Type publishes a supply chain partner's Agile PLM system.
Events (When)
Events define when to publish automated product content for an ATO. Events can be based either on a schedule or on an object's moving to a specified workflow status.
Filters (What)
Filters determine what data elements to publish. Filters provide the ability to configure the data of the element that gets published. ACS provides default filters for all objects.
Criteria (What)
For ATOs, criteria allow automated subscribers to determine what objects they should process. For CTOs, the user decides what objects to process by selecting them on the Selected Contents tab of the CTO.
Subscribers
Agile PLM administrator creates the Subscribers. All applications and external systems that need access to specific product content are defined as subscribers. Subscribers are defined by their configured destinations, filters, criteria, events, assigned roles, and ATO creation data.
Package Services
Package services contain settings used to create the package in the Agile PLM target system for Agile-to-Agile transfers. Package services are defined on the target Agile PLM system in an Agile-to-Agile transfer.
Response Services
Response services define where automated responses are delivered. They are part of an acknowledgment by the remote recipient of the data. Response services are defined on the target Agile PLM system in an Agile-to-Agile transfer.
ACS processes transfer orders in the order they are submitted. Processing transfer orders in this way prevents errors from occurring if the same part is affected by multiple changes. Because of this possibility, ACS must be run on only one managed server in a clustered environment. Configuring ACS in a clustered environment requires setting the appropriate value for the acs.skipServer property in the managed server startup scripts.
In a clustered environment, you must disable the ACS on all managed servers except for one. The Agile PLM installer disables ACS on all managed servers in a cluster by default by setting the acs.skipServer property to true in all managed server startup scripts. When this property is set to true, Agile Content Service does not run on the managed server. If the property is set to any other value (For example, false), or not set at all, Agile Content Service will run on the managed server. To enable Agile Content Service on a managed server, change value for the acs.skipServer property to false in the startup script for the designated managed server.
|
Note: The acs.skipServer property is case sensitive. For proper operation, except for the letter "S" in "Server", all other letters must be in the lower case. |
|
Note: Setting the property in the startup script for the managed server overrides any values in the agile.properties file. For example, if in agile.properties file, acs.skipServer=true, but the setting in the startup script is acs.skipServer=false, then the value in the startup script takes precedence and ACS will run on the managed server. |
To configure the acs.skipServer property in the startup script file, do as follows:
Log into the machine hosting the managed server that will trigger ACS Events. (For example, myhost1).
Change to AGILE_HOME\agileDomain\bin directory, and edit the startup script (For example, startServerAgileManaged1.cmd/sh) for the managed server that triggers ACS Events.
Locate the acs.skipServer property and change the value to false. (For example, from -Dacs.skipServer=true to -Dacs.skipServer=false). See Example 1-1 below.
Save the startup script and restart the managed server.
Example 1-1 Modified startServerAgileManaged1.cmd script
[BEFORE] JAVA_OPTIONS="$JAVA_OPTIONS $JMX_SET -Dweblogic.CompleteWriteTimeout=0 -Dweblogic.system.BootIdentityFile=/u01/app/agile/agile934/agileDomain/config/boot.properties -Dagile.log.dir=/u01/app/agile/agile934/agileDomain/servers/$SERVER_NAME/logs -Dacs.skipServer=true" [AFTER] JAVA_OPTIONS="$JAVA_OPTIONS $JMX_SET -Dweblogic.CompleteWriteTimeout=0 -Dweblogic.system.BootIdentityFile=/u01/app/agile/agile934/agileDomain/config/boot.properties -Dagile.log.dir=/u01/app/agile/agile934/agileDomain/servers/$SERVER_NAME/logs -Dacs.skipServer=false"
Agile PLM provides a default workflow for ATOs and a default workflow for CTOs. Because ATOs and CTOs use automated processes, certain restrictions apply to their workflows.
Because ATO processing is completely automated, the Default ATOs workflow is read-only and cannot be modified. Correct processing of ATOs cannot be ensured if you use a different workflow.
|
Note: Use only the Default ATOs workflow to process ATOs |
Unlike the Default ATOs workflow, the Default CTOs workflow enables you to route CTOs for review. Oracle strongly suggests that you use the Default CTOs workflow to process CTOs.
Any workflow used for CTOs must observe the following restrictions. Correct processing of CTOs cannot be ensured if the workflow you use does not observe these restrictions.
|
Note: When the CTO enters the Released Type status that is the signal to ACS that the CTO is ready to be processed. When a CTO enters the Released Type status, ACS automatically finds the released CTO, automatically processes it, and automatically moves it to the Complete Type status. Any alteration of the Released or Complete Type statuses may prevent correct CTO processing. |
A CTO workflow may have only one Released Type status.
The workflow status immediately following the Released Type status must be the Complete Type status.
The Released Type status must not have any approvers. Therefore, do not modify this workflow status to automatically add approvers, and make sure the Ad Hoc Approvers/Observers property for this status is set to No.
If you need a different CTO workflow, the best way to create one is to open the Default CTOs workflow and use Save As to create the new CTO workflow. In the new CTO workflow, do not alter the Released and Complete Type statuses in any way. However, you may add as many Submit and Review Type statuses as you need and modify the settings of those statuses to suit your needs.
Completed transfer orders, both ATOs and CTOs, provide a record of what, where, and when product content is transferred and whether those transmissions were successful. This enables you to maintain an audit trail of all published product content data.
When you use ATOs to automatically publish product content data, ACS keeps track of what data has been transferred with ATOs. The next time an ATO publishes object data to the same destination, the Agile PLM system compares the object data specified for extraction on the new ATO against the ATO records of previously transferred data. An object that was previously transferred to that destination will not be transferred again, unless you chose to include modified objects. An object with modified data can be transferred again to the same destination.
In contrast, a CTO always publishes the specified data, regardless of whether if it was transferred to that destination previously. If you need to republish data specified on an ATO, a simple method is to open the ATO, and use Save As to create a CTO. You can edit the Selected Content tab of the CTO to specify only the objects you want to republish.
