| Agile Product Lifecycle Management ACS User Guide Release 9.3.3 E39294-02 |
|
 Previous |
 Next |
This chapter provides information and procedures to configure the Agile Content Service™ to generate product records for applications and users, both internally and across the global manufacturing network.
Agile Content Service™ 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, Agile Content Service can be configured 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 Agile Content Service publishes product content, it produces a transfer order that keeps track of what, where, and when product content is transferred. Agile Content Service allows for destination-specific content, ensuring that external entities receive only the information to which they should have access. Roles and privilege masks can be configured to ensure that 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. Agile Content Service 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, Agile Content Service needs to know exactly what content must be transferred, as well as when it goes, where it goes, and a few other factors.
Agile Content Service 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 is used to publish to 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. Agile Content Service 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 theSelected Contents tab of the CTO.
Subscribers
Subscribers are created by the Agile PLM administrator. 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.
Agile Content Service processes transfer orders in the order they are submitted. Processing transfer orders in this order prevents errors from occurring if the same part is affected by multiple changes. Because of this possibility, there is no advantage for Agile Content Service to run on multiple nodes of a clustered environment. Preparing the environment for cluster operations in a Web Logic Cluster requires setting up the acs.skipServer and startAgileCluster.cmd files.
In a clustered environment, you must disable the Agile Content Service on all nodes, except one. To disable Agile Content Service, change the acs.skipServer property value to true in the agile.properties or start script files on those nodes. When this property is set to true, Agile Content Service does not run. If the property is set to any other value, or not set at all, Agile Content Service will run on the node.
|
Note: Adding the property to the startup script file on the managed server, overrides any values in the agile.properties file. For example, if on the Managed server agile.properties is set to acs.skipServer=false, but the token in startup script file is set to acs.skipServer=true, the value in the agile.properties file is replaced by the value in the startup file and the node is skipped. |
To configure the acs.Skipserver property in the startup script file, do as follows:
Navigate to the managed server that is used to trigger the ACS Event. For example, managed Server1.
Open the startAgileCluster.cmd startup file from the location AGILE_HOME\agileDomain\bin on the managed Server that triggers the ACS Event.
Add the token -Dacs.skipServer=value before the weblogic.Server script in the startAgileCluster.cmd startup file. See the Configured startAgileCluster.cmd in the following example below.
Save the startup file Restart the managed Server.
Example 1-1 Configured startAgileCluster.cmd file
("%JAVA_HOME%\bin\java" -server -XX:MaxPermSize=256M -ms1024M -mx1024M -XX:NewSize=256M -XX:MaxNewSize=256M -XX:+UseConcMarkSweepGC -classpath "%CLASSPATH%" %JMX_SET% -Dweblogic.Domain=agileDomain -Dweblogic.Name=SJBUILD01-GX620-ManagedServer1 "-Dbea.home=C:\WlsCluster" -Dweblogic.management.username=%WLS_USERNAME% -Dweblogic.management.password=%WLS_PW% -Djava.awt.headless=true -Dweblogic.ProductionModeEnabled=%STARTMODE% -Dweblogic.log.StdoutSeverity=Error "-Djava.security.policy==C:\WlsCluster\wlserver_10.3/server/lib/weblogic.policy" -Dagile.log.dir=C:\Agile\Agile931/agileDomain/servers/ServerAgileManaged1/log -Dweblogic.management.server=http://SJBUILD03-GX620.agile.agilesoft.com:9001 -Dacs.skipServer=true weblogic.Server
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.
CautionUse only the Default ATOs workflow to process ATOs.
Unlike the Default ATOs workflow, the Default CTOs workflow allows 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 be sure that 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 allows you to maintain an audit trail of all published product content data.
When you use ATOs to automatically publish product content data, Agile Content Service 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.
|
 Copyright © 2010, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|