Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Agile ACS User Guide PDF

Download as pdf or txt
Download as pdf or txt
You are on page 1of 82
At a glance
Powered by AI
The document discusses the lifecycle of packages in Agile Product Lifecycle Management including creation, review, approval, processing, and deletion.

The document states that a package can have statuses like Pending, Unassigned, Closed.

The document outlines that to soft delete a package in Java Client, you open the package and click Delete, and to hard delete a soft deleted package, you find it in the Deleted Packages search and delete it again.

Agile Product Lifecycle Management

Agile Content Service User Guide


v9.3.0.2

Part No. E17303-01


June 2010
Oracle Copyright
Copyright © 1995, 2010, Oracle and/or its affiliates. All rights reserved.

This software and related documentation are provided under a license agreement containing
restrictions on use and disclosure and are protected by intellectual property laws. Except as
expressly permitted in your license agreement or allowed by law, you may not use, copy,
reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish or
display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation
of this software, unless required by law for interoperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be
error-free. If you find any errors, please report them to us in writing.

If this software or related documentation is delivered to the U.S. Government or anyone licensing it
on behalf of the U.S. Government, the following notice is applicable:

U.S. GOVERNMENT RIGHTS


Programs, software, databases, and related documentation and technical data delivered to U.S.
Government customers are "commercial computer software" or "commercial technical data"
pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental
regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject
to the restrictions and license terms set forth in the applicable Government contract, and, to the
extent applicable by the terms of the Government contract, the additional rights set forth in FAR
52.227-19, Commercial Computer Software License (December 2007). Oracle USA, Inc., 500
Oracle Parkway, Redwood City, CA 94065.

This software is developed for general use in a variety of information management applications. It is
not developed or intended for use in any inherently dangerous applications, including applications
which may create a risk of personal injury. If you use this software in dangerous applications, then
you shall be responsible to take all appropriate fail-safe, backup, redundancy and other measures
to ensure the safe use of this software. Oracle Corporation and its affiliates disclaim any liability for
any damages caused by use of this software in dangerous applications.

Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be
trademarks of their respective owners.

This software and documentation may provide access to or information on content, products and
services from third parties. Oracle Corporation and its affiliates are not responsible for and
expressly disclaim all warranties of any kind with respect to third party content, products and
services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages
incurred due to your access to or use of third party content, products or services.

ii Agile Product Lifecycle Management


CONTENTS
Oracle Copyright ................................................................................................................................... ii

Chapter 1 Configuring Agile Content Service .................................................................. 7


About Agile Content Service ................................................................................................................7
How Agile Content Service Works .......................................................................................................7
Setting Up Agile Content Service .........................................................................................................7
Using Agile Content Service in a Clustered Environment .................................................................................................. 8
Workflows for Transfer Orders .............................................................................................................9
Default ATOs Workflow ...................................................................................................................................................... 9
Default CTOs Workflow ...................................................................................................................................................... 9
Tracking Published Data ......................................................................................................................9

Chapter 2 Setting and Editing Destinations ................................................................... 11


Agile Destinations .............................................................................................................................. 11
FTP Destinations ............................................................................................................................... 13
File Destinations ................................................................................................................................ 14
HTTP and HTTPS Destinations ........................................................................................................ 15
Sample HTTP Destination ................................................................................................................................................ 16
JMS Destinations............................................................................................................................... 17
JMS Message Properties ................................................................................................................................................. 19
Editing Destinations ........................................................................................................................... 20
Resetting Destinations ...................................................................................................................... 21
Deleting Destinations ........................................................................................................................ 21

Chapter 3 Setting and Editing Events ............................................................................ 23


Scheduled Events.............................................................................................................................. 23
Workflow Events ................................................................................................................................ 24
Editing Events .................................................................................................................................... 25
Deleting Events ................................................................................................................................. 25

Chapter 4 Setting and Editing Filters ............................................................................. 27


Editing Filters ..................................................................................................................................... 30
Deleting Filters ................................................................................................................................... 31

Chapter 5 Setting and Editing Subscribers .................................................................... 33


Creating Subscribers ......................................................................................................................... 33
Validating Subscribers ....................................................................................................................... 35
Enabling and Disabling Subscribers.................................................................................................. 35

v9.3.0.2 iii
Deleting Subscribers ......................................................................................................................... 35

Chapter 6 Setting and Editing Package Services ........................................................... 37


Editing Package Services .................................................................................................................. 38
Deleting Package Services ............................................................................................................... 39

Chapter 7 Setting and Editing Response Services ......................................................... 41


Creating Response Services ............................................................................................................. 41
Editing Response Services ............................................................................................................... 42
Deleting Response Services ............................................................................................................. 42
Responses and Process Extensions ................................................................................................. 43

Chapter 8 Settings Required for Agile-To-Agile Publishing ........................................... 45


Verifying Agile-to-Agile Publishing .................................................................................................... 47

Chapter 9 Security Considerations................................................................................. 51


Content Transfer Order Originator Field ........................................................................................... 51
Using Agile PLM Roles to Define Destination-Specific Content in Automated Transfer Orders....... 52

Chapter 10 Working with Transfer Orders ..................................................................... 53


About Transfer Orders ....................................................................................................................... 53
Transfer Order Object........................................................................................................................ 53
Cover Page Tab ............................................................................................................................................................... 54
Fields on the Cover Page Tab ................................................................................................ 54
Status on the Cover Page Tab ............................................................................................... 55
Selected Content Tab ....................................................................................................................................................... 56
Where Sent Tab ............................................................................................................................................................... 56
Workflow Tab.................................................................................................................................................................... 58
Attachments Tab .............................................................................................................................................................. 58
History Tab ....................................................................................................................................................................... 59
Creating Content Transfer Orders ..................................................................................................... 59
Creating a CTO with the Create Command...................................................................................................................... 59
Creating a CTO in Java Client ................................................................................................ 60
Creating a CTO in Web Client ................................................................................................ 61
Creating a CTO Using the Save As Feature .......................................................................... 62
Modifying Fields ...................................................................................................................... 62
Deleting Transfer Orders .................................................................................................................................................. 63
Printing Transfer Order Tabs ............................................................................................................................................ 64
Agile Standard Reports for Transfer Orders ..................................................................................................................... 64
IP Transfer Report .................................................................................................................. 64
Chapter 11 Working with Packages ................................................................................................. 67
What are Packages? ........................................................................................................................................................ 67
Intended Audience............................................................................................................................................................ 68

iv Agile Product Lifecycle Management


Package License Requirements ....................................................................................................................................... 68
Who Uses Package Objects? ........................................................................................................................................... 68
Viewing Packages ............................................................................................................................................................ 68
Package Tabs ......................................................................................................................... 68
Status of a Package ............................................................................................................... 72
Packages in Your Inbox.................................................................................................................................................... 72
Package Workflow ............................................................................................................................................................ 73
Package Workflow Diagram ............................................................................................................................................. 75
Partners and Content Managers ...................................................................................................................................... 77
What Is a Partner? .................................................................................................................. 77
What Is a Content Manager?.................................................................................................. 77
Creating a Package .......................................................................................................................................................... 77
Creating a Package Object in Java Client .............................................................................. 77
Creating a Package Object in Web Client .............................................................................. 77
Submitting a Package....................................................................................................................................................... 78
Approving and Rejecting a Package ................................................................................................................................ 78
Importing Product Information from Package Attachments .............................................................................................. 79
Configuring Your Agile PLM System for Agile-to-Agile Communication........................................................................... 79
After Accepting/Rejecting Package Objects ........................................................................... 79
About Searching for Packages ......................................................................................................................................... 80
Final Status of Packages .................................................................................................................................................. 80
Deleting Packages............................................................................................................................................................ 80
Undeleting Packages .............................................................................................................. 81

v9.3.0.2 v
Preface
The Agile PLM documentation set includes Adobe® Acrobat PDF files. The Oracle Technology
Network (OTN) Web site http://www.oracle.com/technology/documentation/agile.html contains the
latest versions of the Agile PLM PDF files. You can view or download these manuals from the Web
site, or you can ask your Agile administrator if there is an Agile PLM Documentation folder available
on your network from which you can access the Agile PLM documentation (PDF) files.

Not e To read the PDF files, you must use the free Adobe Acrobat Reader version 7.0 or later.
This program can be downloaded from the Adobe Web site http://www.adobe.com.

The Oracle Technology Network (OTN) Web site


http://www.oracle.com/technology/documentation/agile.html can be accessed through Help >
Manuals in both Agile Web Client and Agile JavaClient. If you need additional assistance or
information, please contact My Oracle Support (https://support.oracle.com) for assistance.

Not e Before calling Oracle Support about a problem with an Agile PLM manual, please have
the full part number, which is located on the title page.

TTY Access to Oracle Support Services


Oracle provides dedicated Text Telephone (TTY) access to Oracle Support Services within the
United States of America 24 hours a day, 7 days a week. For TTY support, call 800.446.2398.
Outside the United States, call +1.407.458.2479.

Readme
Any last-minute information about Agile PLM can be found in the Readme file on the Oracle
Technology Network (OTN) Web site http://www.oracle.com/technology/documentation/agile.html

Agile Training Aids


Go to the Oracle University Web page
http://www.oracle.com/education/chooser/selectcountry_new.html for more information on Agile
Training offerings.

Accessibility of Code Examples in Documentation


Screen readers may not always correctly read the code examples in this document. The
conventions for writing code require that closing braces should appear on an otherwise empty line;
however, some screen readers may not always read a line of text that consists solely of a bracket or
brace.

This documentation may contain links to Web sites of other companies or organizations that Oracle
does not own or control. Oracle neither evaluates nor makes any representations regarding the
accessibility of these Web sites.

vi Agile Product Lifecycle Management


Chapter 1

Configuring Agile Content Service


This chapter includes the following:

 About Agile Content Service ................................................................................................................................ 7


 How Agile Content Service Works ....................................................................................................................... 7
 Setting Up Agile Content Service ........................................................................................................................ 7
 Workflows for Transfer Orders ............................................................................................................................. 9
 Tracking Published Data ...................................................................................................................................... 9
This chapter contains information about configuring the settings for Agile Content Service.

About Agile Content Service


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.

How Agile Content Service Works


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.

Setting Up Agile Content Service


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)

v9.3.0.2 7
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 the Selected 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
acknowledgement by the remote recipient of the data. Response services are defined on the
target Agile PLM system in an Agile-to-Agile transfer; an ACS Server license is not required to
configure response services.

Using Agile Content Service in a Clustered Environment


When Agile Content Service processes transfer orders, it needs to process them in order.
Processing transfer orders in the order in which they are submitted prevents, for example, 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 the multiple nodes of a clustered environment.

In a clustered environment, Agile Content Service should be disabled on all nodes, except one. To
disable Agile Content Service, change the acs.skipServer property value to true in the
agile.properties file 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.

8 Agile Product Lifecycle Management


Workflows for Transfer Orders
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.

Default ATOs Workflow


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.

Caution Use only the Default ATOs workflow to process ATOs.

Default CTOs Workflow


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.

Not e 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.

Tracking Published Data


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

v9.3.0.2 9
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.

10 Agile Product Lifecycle Management


Chapter 2

Setting and Editing Destinations


This chapter includes the following:

 Agile Destinations ................................................................................................................................................ 11


 FTP Destinations ................................................................................................................................................. 13
 File Destinations .................................................................................................................................................. 14
 HTTP and HTTPS Destinations ........................................................................................................................... 15
 JMS Destinations ................................................................................................................................................. 17
 Editing Destinations ............................................................................................................................................. 20
 Resetting Destinations ......................................................................................................................................... 21
 Deleting Destinations ........................................................................................................................................... 21
Destinations define which resources can accept the extracted content. These are managed from the
Destinations node. With Agile Content Service, you can define the following destination protocols:
 Agile
 FTP
 File
 HTTP/HTTPS
 JMS Queue or Topic

You can now specify the filename extension at the Destination level. That is, any extract that goes
to a given destination will use the specified file extension, if provided. If an extension is not
provided, the default is based on the format of the extraction.

Users cannot create destinations. Destinations must be created and assigned by the administrator
before a user can create a transfer order. When creating a destination, you can also test the
connection to verify that the destination can be located.

The Status column in the Destinations window indicates the status of the last attempted
transmission of data to this destination. When a destination is created or reset, the default status is
Success, even though no transmission has occurred.

Agile PLM provides an example destination with the file protocol that saves the transfer file to the
root directory of the application server. You can use this example destination when creating a
subscriber or CTO, if the properties meet your company’s needs.

Agile Destinations
Agile Content Service can publish to another Agile PLM system. Agile Content Service creates a
package in the target system using Web services. After the package is accepted, the data can be
directly imported from the Attachments tab of the package. Make sure to use aXML format if you
want to directly import the data.

v9.3.0.2 11
Not e To create an Agile destination on your Agile PLM system, you need the following
information about the target Agile PLM system: server URL (including the host name, the
virtual path name, and the port number), the appropriate username and password to use
on the target Agile PLM system, and the name of the package service to select on the
target Agile PLM system. To obtain this information, you may need to contact the
administrator of the target Agile PLM system.

For information about how to configure your Agile PLM system to receive data from another Agile
PLM system, see Setting and Editing Package Services on page 37. (For information about ACS
settings for both source Agile PLM systems and target Agile PLM systems, see Settings Required
for Agile-To-Agile Publishing on page 45.)
To create an Agile destination:
1. Under System Settings > Agile Content Service, double-click Destinations. The Destinations window
appears.

2. Click . The Create Destination dialog box appears.


3. Type a name and a description of the destination in the Name and Description fields.
4. Select Agile from the Protocol list.
5. Select either Yes or No from the Response Expected list.
For information about how to configure your Agile PLM system to send responses from a
destination, see Setting and Editing Response Services on page 41.

6. Click the button next to the Notification User field to display the list of available users. Select
the users to be notified if a transfer failure occurs.
7. Select either HTTP or HTTPS from the Server URL drop-down list.
8. Type the URL and port of the target Agile PLM application server in the host and port fields,
respectively. Type the virtual path name in the virtual path field, which is the last field.
Not e The virtual path is determined when an Agile PLM system is installed. For example,
if the URL used to log in to the Web Client on the target Agile Application Server is:

http://www.clapton.com/Agile/PLMServlet
9. Enter the URL information as shown above, where www.clapton.com is the host name, and Agile is
the virtual path name. The field following the colon (:) is reserved for a port number. 80 is
usually used for HTTP and 443 is usually used for HTTPS. If a port other then 80 or 443 is
being used, the port will appear in the URL used to log in to the Agile Web Client. Omit
PLMServlet, which is the application name. Contact the administrator of the target Agile PLM
application server if you have questions about the correct URL to use.
10. Type the username and password of the target Agile PLM application server in the User Name
and Password fields. Click Grab Package Services.
If the remote Agile PLM system can be properly contacted, the Package Service list is
populated with the package services from the target Agile PLM server.
Not e If the user’s password in the target Agile PLM system changes, be sure to edit the
destination with the new password.

12 Agile Product Lifecycle Management


11. Select the appropriate Package Service from the drop-down list.
Not e You may need to contact the administrator of the target Agile PLM system to
determine which package service you should select.

12. Edit the following destination parameters, if necessary:


 Filename Prefix (default is TO)
 File Number (default is 000001)
The name of the transfer order file consists of the Filename Prefix parameter followed by the
File Number parameter. The File Number parameter increments by one each time a file is
transferred.
13. Click OK.

FTP Destinations
You can publish data to an FTP site. Agile Content Service uses the user name and password, if
set, to log in to the FTP server. You can also verify the connection to the site during creation to
ensure access.

Not e If a file with the same name already exists at the FTP site when the transfer order is
published, it is overwritten.

To create an FTP destination:


1. Under System Settings > Agile Content Service, double-click Destinations. The Destinations window
appears.

2. Click . The Create Destination dialog box appears.


3. Type a name and a description of the destination in the Name and Description fields.
4. Select FTP from the Protocol list.

5. Click the button next to the Notification User field to display the list of available users. Select
the users to be notified if a transfer failure occurs.
6. Type the URL of the FTP site where the transfer order is sent, including port number, if needed,
in the URL or Target Path field.
Not e When entering the URL of the FTP site you do not need to enter ftp://.

7. Type the username and password of the FTP site, if needed, in the User Name and Password
fields.
8. Edit the following destination parameters, if necessary:
 Filename Prefix (default is TO)
 File Number (default is 000001)
 Filename Extension
The name of the transfer order file consists of the Filename Prefix parameter followed by the
File Number parameter with the extension of the Filename Extension parameter. The File

v9.3.0.2 13
Number parameter increments by one each time a file is transferred.
Check Enable User-defined Filename Extension to activate the Filename Extension field. Specify the
filename extension, either .pdx or .axml. All files extracted with this destination have the same
file extension. If no extension is specified, the default is based on the format of the extraction.
9. Select Binary from the Transfer Mode list.
10. Click Test to verify the destination.
When testing the connection to the destination, temporary files are created in the destination
location. You can delete these files after the connection is verified.
11. Click OK.

File Destinations
You can publish data to a file system. Agile Content Service must have access to the fully qualified
path where the file will be located for a successful transfer. Sufficient disk space must also be
available to write the file to the destination. You can verify the connection to the path during creation
to ensure access.
Not e If a file with the same name already exists at the destination when the Transfer
Order is published, it is overwritten.

To create a file destination:


1. Under System Settings > Agile Content Service, double-click Destinations. The Destinations window
appears.

2. Click . The Create Destination dialog box appears.


3. Type a name and a description of the destination in the Name and Description fields.
4. Select File from the Protocol list.

5. Click the button next to the Notification User field to display the list of available users. Select
the users to be notified if a transfer failure occurs.
6. In the URL or Target Path field, type the fully qualified path where the transfer order is to be
located.
Not e You can specify any directory on your network to which the Agile Application Server
can write successfully.

The target path you specify is located on the computer on which the Agile PLM application is
installed. It is not located on the logged-on user’s computer. For example, if you specify C:\temp
the transfer file will be written to the directory named temp on the C drive of the computer where
the Agile PLM application is installed. The transfer file will not be written to the C:\temp directory
of your computer.
UNIX: File destinations can be located in the /opt/Agile folder and its subfolders. Users may not
have write privileges to other folders. Remember to use slashes (/) instead of backslashes (\) in
the path.
7. Edit the following destination parameters, if necessary:

14 Agile Product Lifecycle Management


 Filename Prefix (default is TO)
 File Number (default is 000001)
 Filename Extension
The name of the transfer order file consists of the Filename Prefix parameter followed by the
File Number parameter with the extension of the Filename Extension parameter. The File
Number parameter increments by one each time a file is transferred.
Check Enable User-defined Filename Extension to activate the Filename Extension field. Specify the
filename extension, either .pdx or .axml. All files extracted with this destination have the same
file extension. If no extension is specified, the default is based on the format of the extraction.
8. Click Test to verify the destination.
9. Click OK.

HTTP and HTTPS Destinations


Agile Content Service can publish data to an HTTP server using the POST method. The complete
URL entered in the URL or Target Path field gives the location of the server.

To create an HTTP or HTTPS destination:


1. Under System Settings > Agile Content Service, double-click Destinations. The Destinations window
appears.

2. Click . The Create Destination dialog box appears.


3. Type a name and a description of the destination in the Name and Description fields.
4. Select HTTP or HTTPS from the Protocol list.
5. Select either Yes or No from the Response Expected list.
If Yes is selected, the status of any Transfer Order subscribed with this destination is not
changed to Complete until a Success response is returned from this destination. If a Success
response is not received, no additional Transfer Orders are sent to the destination.
For information about how to configure your Agile PLM system to send responses from a
destination, see Setting and Editing Response Services on page 41.

6. Click the button next to the Notification User field to display the list of available users. Select
the users to be notified if a transfer failure occurs.
7. Type the URL of the HTTP(S) site where the transfer order is to be sent in the URL or Target Path
field.
Not e When entering the URL, you do not need to enter http:// or https://.

8. In the Request File Field field, type the name to use for the MIME part (i.e., section) which will
contain the file data.
(If you need information about how the HTTP POST is constructed, contact Agile Support.)
9. Edit the following destination parameters, if necessary:
 Filename Prefix (default is TO)

v9.3.0.2 15
 File Number (default is 000001)
 Filename Extension
The name of the transfer order file consists of the Filename Prefix parameter followed by the
File Number parameter with the extension of the Filename Extension parameter. The File
Number parameter increments by one each time a file is transferred.
Check Enable User-defined Filename Extension to activate the Filename Extension field. Specify the
filename extension, either .pdx or .axml. All files extracted with this destination have the same
file extension. If no extension is specified, the default is based on the format of the extraction.
Not e You cannot remove these parameters.

10. Click the button next to the Additional Parameters field to display a dialog box. Click the Add
button to enter any additional name/value parameter pairs needed when the URL is submitted.
Click OK.
These parameters will be included as named parts of the generated MIME message.
11. Click Test to verify the destination.
12. Click OK.

Sample HTTP Destination


The following example HTTP destination illustrates how the destination settings are used to
construct the HTTP POST.
Dest in a t io n Sett ing
par am et er
Name HTTP 1
Description Test HTTP destination
Protocol HTTP
Notification User
URL or Target Path localhost:9522
Http:
Request File Field ACS File Data
Filename Prefix TO
File Number 00001
Additional Parameters foo=bar

16 Agile Product Lifecycle Management


POST / HTTP/1.1
Content-Length: 7414
Content-Type: multipart/form-data; boundary=----AlQiUnIdLaEvS-f2a7b238
Cache-Control: no-cache
Pragma: no-cache
User-Agent: Java/1.4.2
Host: localhost
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive

------AlQiUnIdLaEvS-f2a7b238
content-disposition: form-data; name="foo"

bar
------AlQiUnIdLaEvS-f2a7b238
content-disposition: form-data; name="ACS File Data"; filename="TO00001.AXML"
Content-type: Application/Octet-stream;
Content-Transfer-Encoding: binary

...

------AlQiUnIdLaEvS-f2a7b238--

JMS Destinations
Agile Content Service can publish data to Java Messaging Service (JMS). The TIBCO Enterprise,
WebLogic, JMS, Oracle JMS and Oracle AQ are the JMS queues or topics currently supported by
Agile Content Service.

Not e ACS does not support Topics for Oracle AQ and WebLogic.

Before configuring the JMS destination, you may need to make some modifications to the JMS
installation to connect with Agile Content Service.

To create a JMS destination:

Not e You can perform either JMS queue processing or JMS topic processing, depending on
the settings of the Connection Factory and Destination Name parameters of the JMS
destination. See step 8 and step 10 below.

1. Under System Settings > Agile Content Service, double-click Destinations. The Destinations window
appears.

v9.3.0.2 17
2. Click . The Create Destination dialog box appears.
3. Type a name and a description of the destination in the Name and Description fields.
4. Select JMS from the Protocol list.
5. Select either Yes or No from the Response Expected list.
If Yes is selected, the status of any Transfer Order subscribed with this destination is not
changed to Complete until a Success response is returned from this destination. If a Success
response is not received, no additional Transfer Orders are sent to the destination.
For information about how to configure your Agile PLM system to send responses from a
destination, see Setting and Editing Response Services on page 41.

6. Click the button next to the Notification User field to display the list of available users. Select
the users to be notified if a transfer failure occurs.
Not e For the parameters Provider Context Factory, Connection Factory, and Default Provider
URL (in step 7, step 8, and step 9 below), the Agile PLM system fills in the fields with
server-specific defaults. For example, if your Agile PLM system is running on an
Oracle application server, Oracle defaults are used. Verify whether these defaults
are correct for your Agile PLM installation and make any needed modifications.

7. Type the name of the context factory class of the JMS server in the Provider Context Factory field.
The name of the context factory class should be in a format similar to the following examples:
TIBCO: com.tibco.tibjms.naming.TibjmsInitialContextFactory
Oracle JMS: com.evermind.server.rmi.RMIInitialContextFactory
Oracle AQ: com.evermind.server.rmi.RMIInitialContextFactory
WebLogic JMS: weblogic.jndi.WLInitialContextFactory
8. In the Connection Factory field, enter the name of the connection factory that will be obtained
from JNDI tree. This is the name under which the JMS connection factory is registered.
Whether queue processing or topic processing is used is determined by the type of connection
factory named in the Connection Factory field.
The default TIBCO installation provides the following two sample connection factories:
QueueConnectionFactory (for queue processing)
TopicConnectionFactory (for topic processing)
Example values for Oracle JMS are the following:
QueueConnectionFactory (for queue processing)
TopicConnectionFactory (for topic processing)
Example value for Oracle AQ queue processing is as follows:
java:comp/resource/simpleOemsRP/QueueConnectionFactories/QCF
Example value for WebLogic JMS is as follows:
<user defined connection factory>
9. Type the URL, including the address and port, of the host in the Default Provider URL field. The
default value that appears in this field should be valid for the application server's built-in JMS

18 Agile Product Lifecycle Management


provider. Consult your JMS documentation for more information.
For TIBCO, the URL should be in a format similar to the following example:
tibjmsnaming://JMS_ServerName:7222
For Oracle JMS the URL should be in a format similar to the following example:
ormi://Oracle_JMS_ServerName:12401
For Oracle AQ the URL should be in a format similar to the following example:
ormi://Oracle_AQ_ServerName:12401
For WebLogic JMS, the URL should be in the format similar to the following example:
t3://weblogic_serverName:7001
10. Type the name of the queue or topic in the Destination Name field. The name of the queue or
topic depends on how you have configured your JMS server. Consult your JMS documentation
for information about creating and configuring queues and topics.
For example, TIBCO provides the following sample queue and topic:
queue.sample
topic.sample
The example values for Oracle JMS are:
Queue: jms/demoQueue
Topic: jms/demoTopic
The example value for Oracle AQ is:
java:comp/resource/simpleOemsRP/Queues/JMSDEMO_QUEUE
The example value for WebLogic JMS is:
Queue: MyQueue<user defined queue>
11. Type the username and password needed to access the queue in the User Name and Password
fields.

12. Click the button next to the Additional Parameters field to display a dialog box. Click the Add
button to enter any additional name/value parameter pairs. Click OK.
Not e Theses parameters are passed as JMS header properties when delivering content
to the JMS destination.

13. Click Test to verify the destination.


14. Click OK.

JMS Message Properties


Messages sent to JMS destinations contain the following three components:
 message header—used for message identification
 properties—contain application-specific fields

v9.3.0.2 19
 body—holds the content of the message.

ACS adds the following properties to its JMS messages:


P ro p e rt y Nam e P rope rt y Va lue

ClientName "Agile Content Service"

ServerName "Agile Product Lifecycle Management"

ServerVersion The specific Agile server version

AgileRecordLocator The key used to identify the Where Sent row from the
transfer order
TransmissionTimestamp The timestamp when the JMS message was transmitted
displayed as a long number representing the number of
milliseconds since January 1, 1970, 00:00:00 GMT.
AgileTransferObjectNumber The transfer order number

AgileTransferObjectSelectedContentNumbers A semicolon delimited list of the object name or number


from the Selected Content tab. If the object is an item,
then the change number is noted in parenthesis. For
example, if the Selected Content tab for the transfer
order contains change C1 and item P1 at revision A C2,
then this property value would be "C1; P1(C2)".
AgileTransferObjectSelectedContentIdentifiers A semicolon delimited list of the object identifiers from the
Selected Content tab. If the object is an item, then the
change ID is appended following a colon. For example, if
the Selected Content tab for the transfer order contains
change C1 with ID 6001 and item P1 with ID 6002 at
revision A C2 with ID 6003, then this property value would
be "6001;6002;6003".

Editing Destinations
You can edit all of the parameters of the destination, except Protocol. Any future Transfer Orders
referencing the edited destination use the updated settings.

You cannot edit a destination if it is referenced by an enabled subscriber. You must disable the
subscriber before any changes can be made to the destination. See Enabling and Disabling
Subscribers on page 35 for more information.

To edit a destination:
1. Under System Settings > Agile Content Service, double-click Destinations. The Destinations window
appears.
2. Double-click the name of the destination you want to edit.
3. Edit the General Information tab of the destination to make changes to the necessary fields.

20 Agile Product Lifecycle Management


4. Click Save and Close.

Resetting Destinations
If delivery to a destination fails, the failure appears on the Where Sent tab of the transfer order and in
the Transmission Status column on the Destinations window. The Where Sent tab of the transfer order
indicates the transmission status and displays an error message in the Transmission Notes column.

On a destination window, the History tab of the destination displays details indicating which transfer
order caused the failure. After you make any necessary changes to the transfer order or the
destination to correct the problem, you can reset the destination to attempt delivery again.

Once a destination has failed, no other transfer orders can be sent to that destination until it has
been reset. Transfer orders for that destination are queued in the order they were scheduled to be
transmitted. The Transmission Notes column indicates that the transfer order is waiting for another
destination. Once the destination is reset, the transfer orders are transmitted according to their
order in the queue.

To reset a destination:
1. Under System Settings > Agile Content Service, double-click Destinations. The Destinations window
appears.
2. Select the destination to reset.

3. Click .

Deleting Destinations
Destinations can be deleted only if they are not currently assigned to a transfer order or subscriber.

To delete a destination:
1. Under System Settings > Agile Content Service, double-click Destinations. The Destinations window
appears.
2. Select the destination you want to delete.
3. Click .

v9.3.0.2 21
Chapter 3

Setting and Editing Events


This chapter includes the following:

 Scheduled Events ................................................................................................................................................ 23


 Workflow Events .................................................................................................................................................. 24
 Editing Events ...................................................................................................................................................... 25
 Deleting Events .................................................................................................................................................... 25
Events determine when content is transferred to a destination. These are handled from the Events
node.

Events can be based either on a schedule or on an object’s moving to a specified workflow status.
For example, if you wanted to query for objects matching a specific definition every night at
midnight, you would create a scheduled event. Or if you wanted to watch for all change orders
moving to a Released status, you would create a workflow event.

Scheduled Events
Scheduled events are repeated after a specified period of time has elapsed, or at a specific time
hourly, daily, or weekly. When a scheduled event is processed, all Agile PLM objects that meet the
definition specified in the subscriber that have not been processed are extracted.

Agile PLM provides an example scheduled event that is set to trigger at midnight on Saturday and
Sunday. This event can be used when creating a subscriber if the schedule properties meet your
company’s needs. (For information about subscribers, see Setting and Editing Subscribers on page
33.)

To create a scheduled event:


1. Under System Settings > Agile Content Service, double-click Events. The Events window appears.

2. Click . The Create Event dialog box appears.


3. Type a name and a description of the event in the specified fields.
4. Select Scheduled from the Event Type list.

5. Click in the Frequency field to schedule the event.


6. Review the following schedule properties and change them, if necessary.
The default setting is Every X hours Y Minutes. If you accept this default, you must select a time
interval.
Sett in g Acti on
Once A Day Automatically runs the extraction once a day at the designated start time.

v9.3.0.2 23
Sett in g Acti on
Every X Hours Y Specifies the time interval between extractions, calculated from the Starting At
Minutes time:
 If the previous extraction is not finished, the next extraction follows after the
previous extraction is complete.
 The minimum time is 0 hours, 5 minutes: the maximum time for each field is 11
hours and 59 minutes.
Starting At Specifies an absolute time to start checking for subscriber criteria.
If the starting time and ending time are the same, the subscriber criteria are
checked for 24 hours.
Ending At Specifies an absolute time to stop checking for subscriber criteria.
Days Specifies the days to process extractions according to the hourly schedule.

1. Click OK.

Workflow Events
Workflow events enable subscribers to publish data based on a status change of an object. When
the workflow status of an object changes and a subscriber is configured for that particular change,
the data is published. A subscriber cannot act on the first status of a workflow, such as Pending.

Agile PLM provides an example workflow event that is set to trigger when change orders are
released. This event can be used when you create a subscriber if the workflow properties meet your
company’s needs.

Not e Only the object controlled by the workflow is extracted. For example, the Example
Workflow Event uses the Default Change Orders workflow and the Released status. The
triggering event is when any routable object using the Default Change Orders workflow
makes a status transition into the Released status. The routable object and its
associated objects (for example, affected items) and attachments are extracted and
published.

Any changes to an object after Agile Content Service is triggered to process it, but before the
extraction process begins, are reflected in the extracted content. For example, if a subscriber is
configured to publish an ECO at the Review status, but the ECO is immediately promoted to the
Released status, then the extracted status for the ECO may be Released.
To create a workflow event:
1. Under System Settings > Agile Content Service, double-click Events. The Events window appears.

2. Click . The Create Event dialog box appears.


3. Type a name and a description of the event in the specified fields.
4. Select Workflow from the Event Type list.
5. Select a workflow from the Workflow list.

24 Agile Product Lifecycle Management


6. In the Workflow Status field, select a status from the list of available values based on the
selected workflow.
7. Click OK.

Editing Events
You cannot change the event type after the event is created, but you can change the Frequency field
in a scheduled event and the type of workflow in a workflow event.

You cannot edit an event if it is referenced by an enabled subscriber. You must disable the
subscriber before any changes can be made to the event. See Enabling and Disabling Subscribers
on page 35 for more information.

To edit a scheduled event:


1. Under System Settings > Agile Content Service, double-click Events. The Events window appears.
2. Double-click the scheduled event you want to edit.
3. Edit the General Information tab of the event.
4. Make changes to the Name and Description fields, if necessary.

5. Click the button next to the Frequency field.


6. Make the necessary changes to the schedule.
7. Click OK.
8. Click Save.

To edit a workflow event:


1. Under System Settings > Agile Content Service, double-click Events. The Events window appears.
2. Double-click the workflow event you want to edit.
3. Edit the General Information tab of the event.
4. Make changes to the Name and Description fields, if necessary.
5. Select a different workflow from the Workflow list, if necessary.
6. In the Workflow Status field, select a different workflow status, if necessary.
7. Click Save.

Deleting Events
You can delete an event only if it is not assigned to a Subscriber.

To delete an event:
1. Under System Settings > Agile Content Service, double-click Events. The Events window appears.
2. Select the event you want to delete.
3. Click .

v9.3.0.2 25
26 Agile Product Lifecycle Management
Chapter 4

Setting and Editing Filters


This chapter includes the following:

 Editing Filters ....................................................................................................................................................... 30


 Deleting Filters ..................................................................................................................................................... 31
Filters define what content is published in the transfer order. These are managed from the Filters
node.

Not e Filters that you save in the Agile Content Service node are also available for use in the
Agile PLM Export wizard. For more information, see the Agile PLM Import & Export
Guide.

Filters are limited to windows within base classes. If a filter for a specific class makes a tab visible
that a subclass does not have visible, the tab is omitted from the extracted data. For example, the
Page Three tab of an ECO is not visible, but the filter for the Change Orders class allows you to
extract Page Three tabs. When an ECO is extracted using this filter, the data on Page Three is
skipped because it is not visible on the subclass.

You can have multiple filters for the same base classes, but with different filter names. Agile
Content Service provides default filters for the following classes. (Object classes that are not
included in this list are not supported by Agile Content Service.)
 Changes
 Change Orders
 Change Requests
 Deviations
 Manufacturer Orders
 Price Change Orders
 Sites Change Orders
 Stop Ships
 Declarations
 Homogeneous Materials Declarations
 IPC 1752-1 Declarations
 IPC 1752-2 Declarations
 JGP Declarations
 Part Declarations
 Supplier Declarations of Conformance
 Substance Declarations
 Discussions

v9.3.0.2 27
 Items
 Parts
 Documentation
 Manufacturers
 Manufacturer Parts
 Packages
 Part Groups
 Prices
 Published Prices
 Quote Histories
 Product Service Requests
 Problem Reports
 Non-Conformance Reports
 Programs
 Activities
 Gates
 Quality Change Requests
 Audits
 Corrective and Preventive Actions
 Specifications
 Substances
 Substances
 Substance Groups
 Subparts
 Materials
 Suppliers
 Transfer Orders
 Content Transfer Orders
 Users
 User Groups

You can use any of the default filters when creating a subscriber or CTO if the properties meet your
company’s needs, or use them as templates when creating new filters.

You should select your filtering options based on the needs of your integration. Selecting filtering
options that result in more data than you need can have an adverse impact on the performance of
your extractions. For example, if your integration only needs the details of the affected items of a
change and not the full assemblies of those affected items, you should specify an item filter with a

28 Agile Product Lifecycle Management


BOM option indicating Tab Only.

Not e A filter for ATO objects is not needed. To extract data about ATO objects to aXML files,
specify a role that includes privilege masks that allow a user to view ATO objects. When
the selected role allows access to ATO objects, data about the ATO object itself is
extracted and included in the aXML file. This information can be used to troubleshoot
delivery issues.

To create a filter:
1. Under System Settings > Agile Content Service, double-click Filters. The Filters window appears.

2. Click . The Create Filter dialog box appears.


3. Type a name and a description of the filter in the specified fields.
4. Select an object class or base class from the Filter Object Type list.

5. Click the button next to the Viewable Tabs field to display the list of available tabs based on
the selected class
Not e The first tab (Title Block, General Information, or Cover Page) is required for every
filter and is already selected for each object type.

6. Select any additional tabs you want in the filter.


7. Click OK.
Depending on which class you select and the tabs that are viewable in that class, the tab
options displayed and available in the lower part of the Create Filter dialog box are updated.
8. Click the button to display the drop-down list of available tab filter options.
a. Select one of the following options from the BOM Options list:
Not e This field is available only for classes with a BOM tab selected in the Viewable Tabs
field for items or item-associated classes.

 Tab Only: extracts only the displayed table values.


 Tab and Items: you provide a numeric value to indicate the number of levels to be
extracted from the BOM, or you can check a box to indicate all levels.
b. Select one of the following options from the Attachments Options list:
Not e This field is available only for classes with an Attachments tab selected in the
Viewable Tabs field.

 Tab Only: only the Attachment information is packaged with the extracted data.
 Tab and Files: all attachments are packaged with the extracted data.
c. Select one of the following options from the Affected Items Options list:
Not e This field is available only for classes with an Affected Items tab selected in the
Viewable Tabs field for changes or change-associated classes.

 Tab Only: only the Affected Items information is packaged with the extracted data
(includes redline BOM and AML redline data).
 Tab and Items: all items are packaged with the extracted data.

v9.3.0.2 29
d. Select one of the following options from the AML Options list:
Not e This field is available only for classes with a Manufacturers tab selected in the
Viewable Tabs field for items or item-associated classes.

 Tab Only: only the manufacturer information is packaged with the extracted data.
 Tab and Manufacturer Parts: all AML tab and manufacturer parts information is packaged
with the extracted data.
e. Select one of the following options from the General Info Options list:
Not e This field is available only for the Manufacturer Part class.

 Tab Only: only the manufacturer information is packaged with the extracted data.
 Tab and Manufacturer: all manufacturers are packaged with the extracted data.
f. Select one of the following options from the Affected Prices Options list:
Not e This field is available only for the Prices class or price-associated classes.

 Tab Only: only the price information is packaged with the extracted data.
 Tab and Prices: all prices are packaged with the extracted data.
9. Click OK.

Editing Filters
The contents of a filter can be changed if the filter is not assigned to a transfer order or not
referenced by an enabled subscriber.

If the filter is assigned to a transfer order, it can be edited when the transfer order is completed. If
the filter is referenced by an enabled subscriber, you must disable the subscriber to edit the filter.
See Enabling and Disabling Subscribers on page 35 for more information.

To edit a filter:
1. Under System Settings > Agile Content Service, double-click Filters. The Filters window appears.
2. Double-click the name of the filter you want to edit.
3. Edit the Name and Description field on the General Information tab.
4. Make changes to other filter details on the Filter tab.
Not e If you selected the Affected Items tab when you created your filter, you can choose
to send only the BOM and AML redline changes from the Redline changes only drop-
down list on the Filter tab.
 If you selected the Attachments tab along with the Tab and Files attachment option
when you created your filter, you can choose files of only specific types to be
included during export by entering a comma-separated list of file extensions in the
Include File Extensions field.

5. Click Save.

When you edit a filter, if the attachment option is Tab and Files, you can set the Include File
Extensions field, which lets you indicate the file extensions that should be included in the extract. If

30 Agile Product Lifecycle Management


an extension is not specified, then all extensions are included; if an extension is specified, then only
files with the indicated extension(s) are included.

For example, if you specify .doc as the extension (note that the period isn't required), and a part that
you are extracting has both a .doc and a .gif file attached, only the .doc file will be included in the
extract This option is not available when a filter is created, just when a filter is being edited.

Deleting Filters
Filters can be deleted only if they are not currently assigned to an existing transfer order or
subscriber.

To delete a filter:
1. Under System Settings > Agile Content Service, double-click Filters. The Filters window appears.
2. Select the filter you want to delete.
3. Click .

v9.3.0.2 31
Chapter 5

Setting and Editing Subscribers


This chapter includes the following:

 Creating Subscribers ........................................................................................................................................... 33


 Validating Subscribers ......................................................................................................................................... 35
 Enabling and Disabling Subscribers .................................................................................................................... 35
 Deleting Subscribers ............................................................................................................................................ 35
After you configure events, filters, destinations, roles, and criteria, you can create subscribers to
publish data automatically when all of the subscriber requirements are met. A subscriber is
associated with only one event and criteria, but can contain multiple destinations, filters, and roles.
These are managed from the Subscribers node.

Creating Subscribers
Agile PLM provides an example scheduled subscriber and an example workflow subscriber. The
example subscribers incorporate the other Agile Content Service example settings as a template
you can use when creating a subscriber to match your company’s requirements.

To create a subscriber:
1. Under System Settings > Agile Content Service, double-click Subscribers. The Subscribers window
appears.

2. Click . The Create Subscriber dialog box appears.


3. Type a name and a description of the subscriber in the Name and Description fields.
4. Select the subclass from the Subclass list.
This is the ATO subclass Agile Content Service generates when an event occurs that matches
all the properties of this subscriber.
5. Select the Default ATOs workflow from the Workflow list.
For more information about workflows, see Getting Started with Agile PLM.
6. Select ATO Number from the AutoNumber list to select an autonumber source for the selected
subclass.
The default autonumber source is ATO Number. For more information about autonumbers, see
the Agile PLM Administrator Guide. Because ATOs are processed automatically, an
autonumber source is required.
7. Select the object that should be processed by selecting available criteria from the Criteria list.
For more information about criteria and how to create new criteria, see the Agile PLM
Administrator Guide.

v9.3.0.2 33
Not e If you are creating a scheduled event subscriber, be sure to define your criteria as
specifically as possible, to avoid receiving unwanted data in your transfer order. For
example, “All Change Orders released after 8/18/2008” returns a specific group of
change orders, unlike “All Change Orders” which returns every change order in your
system.

8. Select the event specific to this subscriber from the Event list.
9. Click OK. The window of the new subscriber appears.
10. Select Yes or No from the Include Modified Objects drop-down list. (Scheduled Subscribers only)
If yes, new and modified objects since the last processing of the subscriber are published. If no,
only objects that have been created since the initial processing of the subscriber and meet the
Criteria specified by the subscriber are published.
Not e ATOs created from scheduled events will be limited to 100 objects on the Selected
Content tab. For example, if there are 500 objects that meet the given criteria, then
five ATOs are created, which allows ACS to process transfer orders in manageable
amounts while still achieving the desired results.

11. Click the Subscriber Details tab to add destinations, filters, and roles, and to select the transfer
file format.
12. Click to display the Subscriber Detail dialog box.

13. Click to select values for the Destinations, Filters, and Roles fields from the lists of options
available for this subscriber. Roles are applied to further fine-tune or define the data extraction.
For more information about roles, see the Agile PLM Administrator Guide.
14. Select the file type of the transfer file, PDX or aXML, from the Data Format drop-down list.
Product Definition Exchange (PDX) packages contain product content, such as item or change
details, plus BOM data, manufacturer information, drawings, and other attached files. PDX
packages are based on an industry-standard format for encoding structured data in an XML
format. This standard provides an application-independent way to describe product content.
PDX does not support all the object types supported by Agile Content Service.
The Agile Extensible Markup Language (aXML) format is an XML representation of Agile PLM’s
business schema. aXML contains all product content managed in Agile PLM including items,
change details, manufacturer information, problem reports, cost, drawings, and other files.
aXML does support all object types supported by Agile Content Service. An aXML file is a ZIP
file, which includes the XML representation of the Agile PLM content and the associated
attachments.
15. Select the language to use from the Language drop-down list.
The language setting does not affect or translate data in the transfer file; it does determine
which language is used to label object attributes, for example, field and column names.
16. Select a site to use from the Site drop-down list.
The site setting further defines the data extraction. For example, if you select the Hong Kong
site, only BOM information visible for the Hong Kong site will be extracted.
17. Click Save.
The destination detail is displayed in a row on the Subscriber Details tab.

34 Agile Product Lifecycle Management


For each detail row you want to add, click to display the Subscriber Detail dialog box. Follow the
instructions in step 13 through step 17 above.

Validating Subscribers
After you have created your subscriber, you should review the settings to ensure a successful
transfer. Review at least the following settings:
 Destination — Make sure this setting points to the correct location and the connection has been
verified. Make sure that the appropriate personnel are designated for notification.
 Event — If it is a scheduled event, make sure the proper schedule is set. If it is a workflow
event, make sure it is set to the proper workflow and status.
 Filter — Make sure there is a filter for each object you want to transfer.
 Roles — Make sure the correct fields are being extracted.

If the criteria, events, and filters are not well defined for a subscriber, Agile Content Service may not
trigger the ATO or you may not receive the expected results in the ATO.

Enabling and Disabling Subscribers


When a subscriber is created, it is disabled by default. This allows all fields of the subscriber to be
changed before it is used. You must enable a subscriber before it is recognized by the Agile
Content Service.

When a subscriber is enabled, you cannot edit its subscriber details and you cannot edit any of its
referenced destinations, events, or filters. If any of these settings require changes, you must disable
the subscriber.

To enable or disable a Subscriber:


1. Under System Settings > Agile Content Service, double-click Subscribers. The Subscribers window
appears.
2. Select the subscriber you want to enable or disable.
3. Click Enable or Disable .

Deleting Subscribers
Subscribers can be deleted only if they are disabled and not currently assigned to any transfer order
objects.

To delete a subscriber:
1. Under System Settings > Agile Content Service, double-click Subscribers. The Subscribers window
appears.
2. Select the subscriber you want to delete.
3. Click .

v9.3.0.2 35
36 Agile Product Lifecycle Management
Chapter 6

Setting and Editing Package Services


This chapter includes the following:

 Editing Package Services .................................................................................................................................... 38


 Deleting Package Services .................................................................................................................................. 39

Not e For Agile-to-Agile publishing, you must create package services on the target Agile PLM
system; package services are not needed on the source Agile PLM system. For a
summary of the Agile-to-Agile communication configuration tasks required on both the
source Agile PLM system and the target Agile PLM system, see Settings Required for
Agile-To-Agile Publishing on page 45.

Package services are used to define what Package subclass, autonumber source, and workflow are
used when content is received from a remote system through an Agile destination. When you
enable Agile-to-Agile communication, you must configure the target Agile PLM system to properly
create the package object using the correct autonumber source and route it to the correct program
manager. You can configure multiple package services on a target Agile PLM system if you wish to
treat data from each source in a specific manner. However, it is not necessary to create a package
service for each source; several sources can use the same package service.

The following modifications or settings are also required for you to successfully define and use
package services:
 The following package object fields must be visible on the Cover Page tab of the Package object
class:
 Response Expected
 Source GUID
 XFER Order Locator
 Create or identify a user who has a role that provides the ability to create, modify, and delete
package objects and the ability to change the status of the package object to the required
workflow status. You must provide this user’s username and password to the administrator of
the source Agile PLM system; it is needed to define a destination on the source Agile PLM
system (see Setting and Editing Destinations on page 11). If the package service moves the
package object to the Submit status, then the privilege masks in the default Partner role are
sufficient if you modify the Modify Pending Package privilege mask by adding the following
fields to the Selected list in the Applied To property:
 Packages.Cover Page.Program Manager
 Packages.Cover Page.Response Expected
 Packages.Cover Page.Source GUID
 Packages.Cover Page.XFER Order Locator
If you do not want to modify this privilege mask, use the Partner role and privilege masks as a
guide to create the necessary role.

v9.3.0.2 37
Not e Verify that the package service will work successfully with the package object
configuration, package workflow settings, and login user role. For information, see
Verifying Agile-to-Agile Publishing on page 47.

To create a package service:


1. Under System Settings > Agile Content Service, double-click Package Services. The Package
Services window appears.

2. Click . The Create Package Service dialog box appears.


3. Type a name and a description of the subscriber in the Name and Description fields.
4. Select Package from the Subclass list.
Not e If you have defined a specific package subclass for use in package services, select
that subclass from the list.

5. Select Package Number as the autonumber from the Number Source list.
6. Select Default Packages from the Workflow list.
Not e If you have defined a specific package workflow for use in package services, select
that workflow from the list.

7. Select a workflow status from the Workflow Status drop-down list.


Agile recommends using the Submitted workflow status to ensure that the receiving program
manager is notified about the package.
When an Agile-to-Agile transfer occurs, the package object is created on the target Agile PLM
system and the package workflow status is set to the status specified in the Workflow Status field
of the package service.
Not e When creating a package service with a target package workflow status other than
Pending, make sure the target workflow allows changes directly from the Pending
status to the status to be used (determined by the Manual Valid Next Status
property for the Pending status if the status to be used is not the next status after
Pending in the workflow). Also make sure that the logged-in user specified in the
target Agile PLM system destination has the privilege to make the change (Change
Status (CS) privileges for packages) in the target Agile PLM system.

8. Click OK.

Editing Package Services


You can edit all of the parameters of the package service except the Subclass field.

To edit a package service:


1. Under System Settings > Agile Content Service, double-click Package Services. The Package
Services window appears.
2. Double-click the package service you want to edit.

38 Agile Product Lifecycle Management


3. Edit the General Information tab of the service to make the necessary changes.
4. Click Save and Close.

Deleting Package Services


You can delete a package service at any time. Because a package service does not restrict or
define other ACS settings and does not have relationships with database objects, your ability to
delete it is not restricted.

Not e If a source Agile PLM system attempts to deliver content to a deleted package service,
the content transfer will fail.

To delete a package service:


1. Under System Settings > Agile Content Service, double-click Package Services. The Package
Services window appears.
2. Select the package service you want to delete.
3. Click .

v9.3.0.2 39
Chapter 7

Setting and Editing Response Services


This chapter includes the following:

 Creating Response Services ............................................................................................................................... 41


 Editing Response Services .................................................................................................................................. 42
 Deleting Response Services ................................................................................................................................ 42
 Responses and Process Extensions ................................................................................................................... 43
A remote target Agile PLM system, HTTP/S destination, or JMS destination can relay an accept or
reject message back to the source Agile PLM system after the expected data is received. These
messages are called responses. Responses are recorded in the Response column of the Where Sent
tab (on transfer orders in the source Agile PLM system) of the transfer order corresponding to the
responding destination. An Agile PLM target system makes use of a response service and pre-built
process extensions to respond to the source Agile PLM system. Process extensions are used to
determine what package workflow state should initiate a response, and the response service is
used to define how and where to respond.

To define a response service, you must enable the process extensions and define their Initiate
From property from the Process Extension node and you must define, from the Workflows node, which
package workflow status initiates a response. See Process Extensions. Where the response is sent
is managed from the Response Services node.

Not e Package Services and Response Services are defined on an Agile PLM system that
receives Agile-to-Agile data. (See Settings Required for Agile-To-Agile Publishing on
page 45.)

The Global Unique ID (GUID) attribute in a response service definition is a non-editable text field
that uniquely defines the source Agile PLM server. It is used to determine how to respond to the
package sender. The target system looks up the GUID and locates the corresponding response
service. That response service has all the information needed to contact the package sender, such
as username, password, protocol, and host.

Creating Response Services


When you create a new response service, the GUID from the source Agile PLM system is retrieved
automatically. After the values for server, port, protocol, and context are set, the source Agile PLM
system is contacted. If the contact is successful, the GUID is retrieved and the response service’s
GUID property is set automatically.
To create a response service:
1. Under System Settings > Agile Content Service, double-click Response Services. The Response
Services window appears.

2. Click . The Create Response Service dialog box appears.


3. Type a name and a description of the destination in the Name and Description fields.

v9.3.0.2 41
4. Select HTTP or HTTPS from the Server URL drop-down list.
5. Type the URL and port of the target Agile PLM application server in the host and port fields,
respectively. Type the virtual path name in the virtual path field, which is the last field.
The virtual path is determined when an Agile PLM system is installed. For example, if the URL
used to log in to the Web Client on the target Agile PLM application server is:
http://www.clapton.com/Agile/PLMServlet
6. Enter the URL information as shown above, where www.clapton.com is the host name, and Agile is
the virtual path name. The field following the colon (:) is reserved for a port number. 80 is
usually used for HTTP, and 443 is usually used for HTTPS. If a port other then 80 or 443 is
being used, the port will appear in the URL used to log in to the Agile Web Client. Omit
PLMServlet, which is the application name. Contact the administrator of the target Agile PLM
application server if you have questions about the correct URL to use.
7. Type the username and password of the source Agile PLM application server in the Username
and Password fields.
8. Click Retrieve GUID to verify the destination.
If the destination is verified, the GUID field is completed automatically.
9. Click OK.

Editing Response Services


You can edit all of the parameters of the response service.

To edit a response service:


1. Under System Settings > Agile Content Service, double-click Response Services. The Response
Services window appears.
2. Double-click the response service you want to edit.
3. Edit the General Information tab make the necessary changes.
Not e If you change the Server URL, Username, or Password field, click Retrieve Response
Service to automatically verify and update the GUID field.

4. Click Save and Close.

Deleting Response Services


You can delete a response service at any time. Because a response service is neither enabled nor
disabled, your ability to delete it is not restricted.

Not e If you delete a response service, your target Agile PLM system will no longer be able to
respond to the referenced source Agile PLM system.

To delete a response:
1. Under System Settings > Agile Content Service, double-click Response Services. The Response

42 Agile Product Lifecycle Management


Services window appears.
2. Select the response service you want to delete.
3. Click .

Responses and Process Extensions


The reject and accept responses are generated by process extensions. Agile PLM provides two
process extensions that you can use to send an accept or reject response to the source Agile PLM
system. To use the Agile-supplied process extensions successfully you must do the following:
 From the Classes node, on the Package base class Process Extensions tab, you must assign the
accept and reject process extensions to list them on this tab.
 From the Process Extensions node, you must enable the accept and reject process extensions.
 From the Process Extensions node, you must open the two process extensions and modify the
Initiate From field on the process extension General Information tab. Select either Workflow State
(to initiate the process extension upon entering a specific workflow status) or Actions Menu (to
manually initiate the process extension from the Actions menu. You can select both, if they
meet your needs. (The Tools Menu selection is not appropriate for transfer responses.)
 From the Workflows node, you must modify the workflow for the Package subclass specified in
the package service.

The "Process Extensions" chapter in the Agile PLM Administrator Guide explains in detail how to
select and enable process extensions and how to modify the appropriate workflow.

v9.3.0.2 43
Chapter 8

Settings Required for Agile-To-Agile


Publishing
This chapter includes the following:

 Verifying Agile-to-Agile Publishing ....................................................................................................................... 47


To successfully publish content data from a source Agile PLM system to another target Agile PLM
system, the appropriate Agile Content Service settings and process extension settings must be
defined. The same settings are not required for both the source and target system. The following
two diagrams and tables summarize the settings required when the source Agile PLM system does
not request a response and the settings required when the source Agile PLM system does request
a response.

Source Agile PLM System Target Agile PLM System

ACS creates an ATO, releases the ATO, and publishes Transfer order received; package service creates a
content to subscribers (target Agile PLM systems) package object and attaches the content file.
or Package is submitted to the program manager.
User creates and releases a CTO to publish content to
target Agile PLM system.

Source Agile PLM system settings Target Agile PLM system settings
Define the required Agile destinations. Define the package service, which specifies what Package
subclass, autonumber source, workflow, and workflow
(See Setting and Editing Destinations on
status (typically Submitted) to use when receiving content
page 11.)
in an Agile-to-Agile transfer.
(See Setting and Editing Package Services on
page 37.)
Define the required event.
(See Setting and Editing Events on page 23.)
Define the required criteria or use Agile-supplied
criteria.
(See Criteria.)
Define the required filters or use Agile-supplied
filters.
(See Setting and Editing Filters on page 27.)
Define the required roles or use Agile-supplied
roles.
(See Roles.)

v9.3.0.2 45
Define the subscriber, specifying the event, criteria,
destinations, roles, and filters you have previously
defined. (See Setting and Editing
Subscribers on page 33.)

When the source Agile PLM system requests a response, the target Agile PLM system must also
have response services defined, which also requires settings for process extensions and package
object workflows. See the following diagram and table.

For details about the required settings, refer to the following table and the sections and chapters
listed below.

Source Agile PLM System Target Agile PLM System

ACS creates an ATO, releases the ATO, and publishes


content to subscribers (target Agile PLM systems) Transfer order received; package service creates a
or package object and attaches the content file.
User creates and releases CTO to publish content to Package is submitted to program manager.
target Agile PLM system.

Package object released and accepted or it is


Accept or reject response received. canceled and rejected. An accept or reject response
On the Where Sent tab of ATO or CTO, the Response field is sent back to the source Agile PLM system relying
is updated in rows where the target Agile PLM system is on this information.
the destination.
(Depending on the configuration of the process
extensions, a response may also be initiated
manually from the Actions menu.)

Source Agile PLM system settings Target Agile PLM system settings
Define the required Agile Destinations. Define the Package Service, which specifies what
Package subclass, autonumber source, workflow, and
(See Setting and Editing Destinations on
workflow status (typically Submitted) to use when
page 11.)
receiving content in an Agile-to-Agile transfer. (See
Setting and Editing Package Services on page
37.)
Define the required Event. Define the Response Service, which specifies the details
required to relay an accept or reject message back the
(See Setting and Editing Events on page 23.)
source Agile PLM system.
(See Setting and Editing Response Services on
page 41.)

46 Agile Product Lifecycle Management


Define the required criteria or use Agile-supplied Verify that on the Package base class node, the process
criteria. extensions have been assigned on the Process
Extensions tab. Verify that for the Package class, the
(See Criteria.)
proper fields are visible on the object Cover Page tab.
(See Responses and Process Extensions on page
43 and Process Extensions.)
Define the required filters or use Agile-supplied Verify that the Accept Package Response and Reject
filters. Package Response process extensions are properly
configured:
(See Setting and Editing Filters on page 27.)
 The process extensions must be enabled.
 To automatically initiate the process extension,
Workflow State must be included in the process
extension Initiate From field.
 To manually initiate the process extension, Actions
Menu must be included in the process extension
Initiate From field.
(See Process Extensions.)
Define the required roles or use Agile-supplied
roles.
(See Roles.)

Define the Subscriber, specifying the event, criteria, Modify the package workflow status criteria to specify the
destinations, roles, and filters you have previously statuses at which an accept and reject response will be
defined. (See Setting and Editing initiated, typically the Released and Canceled statuses.
Subscribers on page 33.) (See Process Extensions.)

Verifying Agile-to-Agile Publishing


Before you attempt an Agile-to-Agile transfer, you can perform the following simple test which
verifies that the login user on the target Agile PLM system can perform the actions specified in the
package service. This test verifies that the package object and workflow are configured correctly,
and that the login user has the necessary privileges. Perform the steps in the order given.

To verify the package service, package object, package workflow and login user settings:
1. Log in to the target Agile PLM system using the username and password specified in the
destination (on the source Agile PLM system) for this target Agile PLM system. (See Setting
and Editing Destinations on page 11.)

v9.3.0.2 47
Not e If a user on the source Agile PLM system (for example, the administrator of the
source Agile PLM system) logs in to the target Agile PLM system and performs this
test, you will also verify that the source Agile PLM system can log in automatically
from outside the target Agile PLM system firewall. However, a user on the target
Agile PLM system can also perform this test and verify that the package object and
workflow configuration and login user privileges are correct.

2. Create a package object. Use the package subclass specified in the target Agile PLM system
package service.
3. Delete the package object. This verifies that the user has the necessary privilege to delete the
package object.
4. Create another package object. Use the package subclass specified in the target Agile PLM
system package service.
5. On the Cover Page tab of the package object, verify that the following fields are available for
modifying. You should be able to enter text or make a selection from a drop-down list or dialog
box.
 Originator (Select a different user.)
 Date Originated (Select a different date.)
 Description (Enter text.)
 Workflow (Select the workflow specified in the target Agile PLM system package service.)
 Modify the following three fields. In an Agile-to-Agile content transfer, these fields are filled
in automatically; however, for the content transfer to be successful, the fields must be both
visible on the Cover Page tab and available for modifying. If you can modify these fields
manually, you have verified that the login user has the necessary privilege masks for these
fields, and, therefore, the fields can be successfully filled in automatically during an Agile-
to-Agile transfer.
 Response Expected (Select a setting from the drop-down list.)
 Source GUID (Enter text.)
 XFER Order Locator (Enter text.)
6. Click Save.
7. Click the Attachments tab to display it.
8. Verify that the login user can attach a file to the package object.
Choose Add | Files and add a file to the Attachments tab. Use any file type; a simple text file is
sufficient.
9. Click the Workflow tab to display it.
10. Verify that the login user can change the workflow status of the package object to the workflow
status specified in the package service.
On the workflow flowchart, click the workflow status specified in the package service. (See
Setting and Editing Package Services on page 37.)
For example, if the package service specifies the Review status, you should be able to click
that status box in the flowchart and change the workflow status of the package object. If the
Review status is not available and clickable, verify that the workflow you are using allows a
change in status from the Pending status directly to the Review status. This is determined by

48 Agile Product Lifecycle Management


the Manual Valid Next Status property of the Pending status. Also verify that the role of the
login user has the appropriate privilege to change the status from Pending to Review. Refer to
the following table for more details.
Not e The Default Packages workflow and the Agile-supplied Partner role (modified as
explained in Setting and Editing Package Services on page 37) allow the login user
to move a package from the Pending status directly to the Submit status. If you are
using the Default Packages workflow and the Partner role, and, in the package
service, you selected a workflow status other than Submit, you must make the
appropriate modifications to the package workflow and login user role.

If you can perform the preceding steps successfully, the login user can create a package object,
modify specific fields, attach a file, and move the package object to the specified workflow status.
These are the same actions specified in the package service.
Problem Possible cause Solution

In the source Agile PLM The target Agile PLM system user In the target Agile PLM system, modify
system, on the Where Sent specified as the login user in the the role of the login user to one that has
tab of the ATO, the error Agile PLM source system destination the necessary privileges. See Setting
“Insufficient Privilege” does not have the necessary and Editing Response Services
appears. privileges to either create a package on page 41.
object in the target system or does
not have the necessary privileges to
move the package object to the
specified workflow status.
In the target Agile PLM If the login user on the target Agile If the login user has the necessary
system, the package object is PLM system has the necessary change status privileges (see row
created, but does not move to privileges (see row above), then the above), verify that the package
the correct workflow status; package workflow on the target workflow (on the target system) you are
the error “Insufficient system may not allow the package to using allows a status change directly
Privilege” appears. move directly to the workflow status from the Pending type status to the
specified in the package service. status specified in the package service.
This is determined in the workflow by
the Manual Valid Next Status property
for the Pending status. Refer to the note
in step 7 under “Setting and Editing
Response Services” for more details.
Duplicate package objects If the package object on the target In the target Agile PLM system, verify
appear on the target Agile system cannot be moved to the that the login user has a role that
PLM system. workflow status specified in the includes a Delete privilege mask for
package service (for any reason, package objects. If not, modify the role
including, but not limited to, or assign an appropriate role. Also
insufficient login user privileges), the verify that the login user has a role with
target Agile PLM system attempts to the necessary privileges to move the
delete the package object. If the login package object to the workflow status
user does not have the appropriate specified in the package service. See
Delete privilege mask, this may fail, Setting and Editing Response
and thus it is possible to have Services on page 41.
duplicate package objects.

v9.3.0.2 49
50 Agile Product Lifecycle Management
Chapter 9

Security Considerations
This chapter includes the following:

 Content Transfer Order Originator Field .............................................................................................................. 51


 Using Agile PLM Roles to Define Destination-Specific Content in Automated Transfer Orders .......................... 52
Roles and privileges play an important part in limiting and defining the Agile PLM content that is
extracted by a transfer order.

Content Transfer Order Originator Field


The Originator field on the Cover Page tab of a CTO is an important component of the security
safeguards for CTOs. The roles and site assignments of the user who is specified in the Originator
field are used to further define the data that is extracted. In ATOs, the roles used to extract data are
defined in the subscriber. In contrast, for CTOs, the roles used to extract data are defined by the
roles of the user specified in the Originator field.

For example, if the originator user does not have the necessary privileges to view items assigned to
the Libra product line, when BOM items are extracted, any Libra product line items will not be
extracted.

In a similar manner, if the originator user is not assigned to the Hong Kong site, Hong Kong BOM
data will not be extracted, even if Hong Kong is selected in the Site column on the Destinations tab.

By default, when a CTO is created, the Originator field is populated with the name of the creator of
the CTO. Using the Agile-supplied Content Manager role, the content manager user is able to select
a different user in the Originator field and also release the CTO, thus publishing product content that
the content manager cannot access. Before assigning the Content Manager role to users,
determine whether this ability meets your company’s needs.

If you do not want the originator of a CTO to publish data he cannot access, one way is to modify
the existing Content Manager role, or to create a similar role that includes a Change Status privilege
mask for CTOs with a criteria that forces the user who changes the status of a CTO to be the user
whose name is in the Originator field of the CTO (Cover Page.Originator Equal to $USER). If you
create and assign a role with this restricted privilege mask, the user listed in the Originator field of
the CTO (by default, the creator of the CTO) must also be the user who changes the status and
releases the CTO.

If you create additional roles and privilege masks for CTO objects, keep this powerful security
feature in mind. If you allow a user to both modify the Originator field and release the CTO, this
makes it possible for the creator of a CTO to specify a user with more powerful roles than the
creator user has, which may violate your company’s security objectives.

v9.3.0.2 51
Using Agile PLM Roles to Define Destination-
Specific Content in Automated Transfer Orders
When you define a subscriber, the roles you specify for each destination on the Subscriber Details tab
(in conjunction with the specified Filters and Subscriber Sites settings for each destination) determine
exactly what product content is extracted. The flexibility of Agile PLM roles, privilege masks, and
criteria allows you to create, if needed, roles for each destination. Agile PLM Discovery and Read
privilege masks determine which objects can be extracted. The Applied To property of these
privilege masks determines which object tabs and fields can be extracted. You can specify
individual fields in the Applied To property of the privilege mask, thus defining, field by field, the
specific product content that can be extracted.

For more information about roles, privilege masks, and criteria see the Agile PLM Administrator
Guide.

52 Agile Product Lifecycle Management


Chapter 10

Working with Transfer Orders


This chapter includes the following:

 About Transfer Orders ......................................................................................................................................... 53


 Transfer Order Object .......................................................................................................................................... 53
 Creating Content Transfer Orders ....................................................................................................................... 59
 Working with Packages ....................................................................................................................................... 67

About Transfer Orders


Transfer orders keep track of what, where, and when product content is transferred by Agile
Content Service (ACS). There are two types of transfer orders: automated transfer order (ATO) and
content transfer order (CTO). ATOs are created automatically by system-level subscribers that are
configured by your Agile PLM administrator. CTOs are created when product content is published
on demand by end users.

Transfer Order Object


This section includes the following topics:
 Cover Page Tab
 Selected Content Tab
 Where Sent Tab
 Attachments Tab
 Workflow Tab
 History Tab

When you view a transfer order, you are viewing a set of tabs on the Transfer Order window (Java
Client) or page (Web Client). The following table lists the tabs for transfer orders and the section
where each tab is described.
Transfer order tab name Tab information includes

Cover Page tab General information about the transfer order.

Selected Content tab Objects being transferred by the transfer order.

Where Sent tab Delivery details about the transfer order and extraction.

v9.3.0.2 53
Transfer order tab name Tab information includes

Workflow tab Where the transfer order is in the assigned workflow.

Attachments tab Attached files.

History tab Log of all actions taken on the transfer order.

Cover Page Tab


The Cover Page tab has fields that contain the general information about the transfer order. Agile
PLM automatically completes some of the fields; you complete the rest.

To edit fields of an unreleased transfer order, click the Edit button. You may not be able to edit the
contents of some fields.

Not e You cannot edit the Cover Page fields of an ATO.

Fields on the Cover Page Tab


By default, the Cover Page tab contains the fields listed in the following table. Agile PLM
administrators can configure fields on the Cover Page tab.
Not e All fields are completed by Agile Content Service for ATOs.

Field Contains... Completed...

Transfer Order Type Displays CTO or ATO. Automatically or manually, when created.
Transfer Order Number The number of the transfer order. Automatically or manually, when created.
Description Text that describes the transfer order. The Manually for CTO; automatically for ATO.
maximum length is set by the Agile PLM
administrator.
Originator The user who created the CTO (can be selected Automatically or manually, when created.
from a drop-down list) or the subscriber of the
or
ATO.
Subscriber
Note: For CTOs, the roles assigned to the user
listed in this field are the roles used to limit and
define what data is extracted by the transfer
order. For ATOs, roles are specified in the
subscriber details.

54 Agile Product Lifecycle Management


Field Contains... Completed...

Status Transfer order status; if no workflow has been Automatically, when created; updated as the
selected, this field is Unassigned. transfer order moves through the assigned
workflow.
Workflow The name of the workflow being used to move Manually, whether one or more than one
this transfer order through the release process. workflow applies. If more than one workflow
applies to a CTO, the workflow selection can be
changed as long as the CTO is in the Pending
status type. Selecting the blank field in the
Workflow drop-down list switches the CTO to the
Unassigned status. For more information about
workflows, see Getting Started with Agile PLM.

Date Originated The date the transfer order is created. Automatically, when created.
Date Released The date the transfer order is released. Automatically, when released.
Final Complete Date The date the transfer order is completed. Automatically, when completed.

Status on the Cover Page Tab


Agile PLM uses a workflow stamp in the upper right corner of the Cover Page tab to indicate the
status of a transfer order. Your Agile PLM administrator defines the name of each status in each
workflow.

Your Agile PLM administrator may have created customized workflows and statuses for your
company. The table below shows only the default transfer order workflow statuses.
Status name Status definition

Unassigned No workflow has been assigned to this transfer order. The originator may still be developing the
transfer order (CTOs only). No statuses are displayed on the Workflow tab.
Pending The workflow has been assigned. The originator may still be developing the transfer order
(CTOs only). It has not yet been approved or perhaps even completed.
Review The transfer order is under review. It has not yet been approved or completed (Default CTOs
workflow only).
Released The transfer order is being processed by Agile Content Service.
Complete Agile Content Service automatically moves a Released transfer order to Complete status after
it is successfully processed. If a transfer order cannot be successfully processed, it remains in
Released status, and an error appears on the Where Sent tab.

Not e Do not modify any setting in the Released or Complete status in the default CTO
workflow. Transfer orders extract data only while in Released status with enough
time allowed for the extraction thread to process it.

The Workflow tab shows all the statuses the transfer order has been through, and the statuses
remaining to complete the extraction process. (See “Workflow Tab”)

v9.3.0.2 55
With appropriate privileges, you can switch a transfer order to another status with the Workflow tab
or the Next Status button.

Selected Content Tab


The Selected Content tab lists the objects that are being transferred by the transfer order. You must
have the required privileges to modify the Selected Content tab.
 The Selected Content tab includes the following fields that are used to define what is extracted
when the transfer order is processed:
 Type — the type of the object.
 Icons indicating the type of object, whether it has attachments, whether it has pending
changes, and, if it is an item object, whether it has AML information on its Manufacturers tab.
 Name/Number — the number assigned to the object.
 Description — the description of the object.
 Lifecycle/Status — the current lifecycle phase or workflow status of the object.
 Rev — the revision of the object to be transferred when the transfer order is released.

To view an object listed on the Selected Content tab, click its number.

Where Sent Tab


The Where Sent tab lists the transfer information of the transfer order. You must have the required
privileges to modify the Where Sent tab.

The Where Sent tab includes the following fields:


 Destination — where the transfer order is published.
Agile PLM provides file, FTP, HTTP(S), JMS queue or JMS topic, and Agile system as
destination types. For example, a content manager at an OEM uses Agile Content Service to
publish a CTO containing a released assembly to an EMS provider for quoting. That EMS
provider may have set up an FTP site (destination) where the CTOs should be published. Or
upon the release of an ECO, a content manager publishes a CTO to their EAI system to update
the appropriate downstream systems with the latest released assembly. That EAI system would
be listed as the destination for the CTO.
Destinations are defined by your Agile PLM administrator.
 Filters — the extraction details for the transfer order.
Filters determine what tabs are extracted for the objects listed on the Selected Content tab.
Filters are grouped by base classes (for example, Change) and classes (for example, Change
Orders). If a filter for a specific class includes a tab that is not visible, the tab is omitted from the
extracted data. For example, the Page Three tab of an ECO is not visible, but the filter for the
Change Orders class allows you to extract Page Three tabs. When an ECO is extracted using
this filter, the data on Page Three is skipped because it is not visible in the ECO subclass.
Default filters are available for all objects. Additional filters are created by your Agile PLM
administrator.

56 Agile Product Lifecycle Management


 Data Format/Data Extraction — the file type of the transfer file: aXML or PDX.
Agile Extensible Markup Language (aXML) format is an XML representation of Agile PLM’s
business schema. aXML contains all product content managed in Agile PLM. When the transfer
order is published, a .ZIP file containing the aXML file and any attachments is created.
Product Definition Exchange (PDX) packages are an industry-standard format for encoding
structured data in an XML format. Like aXML, a PDX package is also a zipped file with an
attachment payload. The advantage of PDX is that it is an application independent way to
describe product content. The disadvantage is that it may not support all Agile objects and
data. For example, Price objects and price change orders (PCOs) cannot be exported in PDX
format. For more information about PDX packages, see “Working with Packages.”
 Language — determines which language is used to label object attributes, for example, field and
column names. No language translation of data is performed.
 Site — one of the filters used to extract data. For example, if you select the Hong Kong site,
only data visible for the Hong Kong site is extracted. To extract data for all sites, select All.
 Date Sent — the date the transfer order is released.
 Transmission Status —the status of the transmission:
 Pending: the transfer order is being processed.
 Extracting: the data in the row (Selected Content and Filters) is currently being extracted
into the specified file format.
 Transmitting: the data was successfully extracted and is currently being transmitted to the
specified destination.
 Success: the data was successfully transmitted.
 Failure: the data extraction or transmission was not completed.
 Transmission Notes — the message describing the reason for the transmission failure, if one
occurs.
 Response — the acknowledgment of the transfer order by the remote system.
A remote system or destination can relay an accept or reject message to Agile PLM after the
expected data is received. Responses are defined by your Agile PLM administrator.
 Roles — (appears on the Where Sent tab of ATOs only) the roles used to extract data for this
transfer order.
For ATOs, roles are specified in the subscriber definition. Roles further fine tune and define the
data to be extracted. For example, if the roles selected do not allow a user to read
manufacturer part objects, then manufacturer part object data will not be extracted even though
manufacturer part objects appear on the Selected Content tab. The output file will contain a
section of content not readable by the role, but the details will display No Privilege.

Note For CTOs, the roles used to extract data are defined by the roles assigned to the user who is
listed in the Originator field in the Cover Page tab.

If multiple transfer orders are being published to the same destination and that destination fails, only
the first transfer order’s Where Sent tab indicates the failure. The status of the remaining transfer
orders does not change until the first transfer order is successfully transmitted. The remaining
transfer orders are queued in the order they were scheduled to transmit. If a transfer order is failing
and blocking a destination, you should delete the failing transfer order.

v9.3.0.2 57
The Transmission Notes column indicates that the transfer order is waiting for another destination.
Once the failed destination is reset (your Agile PLM administrator must reset the failed destination),
the transfer orders are transmitted according to their order in the queue. This is done to maintain
situations where data must be transmitted in sequential order.

Not e A transfer order is processed when it enters the Released status. Data extraction takes
place at this time, not at the time the transfer order was created. Any changes to an
object after the transfer order is created, but before the extraction process begins, are
reflected in the extracted content. For example, if an ECO is at the Review status when
the transfer order is created, but the ECO is promoted to the Released status before the
data is extracted, then the extracted status for the ECO is Released.

Workflow Tab
The Workflow tab shows where the transfer order is in the assigned workflow and lists present and
past signoff information. It also shows all the approvals and rejections made during each approval
cycle.

The Signoff History table on the Workflow tab includes the following fields:
 Status Code —
 Reviewer — the user who reviewed the transfer order. This can be an approver or an observer,
and it can be a single user or a user group.
 Action — the action taken by the reviewer.
 Required — whether the reviewer is a required reviewer (approver) or not (observer).
 Local Client Time — the date and time of the action.
 Signoff Comments — any comments made by the reviewers (approvers and observers) during
signoff.
 Signoff User — the name of the user who actually approved or rejected the transfer order.
 Status Changed By — the name of the user who switched the status.
 Workflow Status — the name of the status.
 Workflow — the name of the workflow that the transfer order is following.
 Signoff Duration —

The Workflow tab also includes a chart of the workflow, which shows all possible status names for
the transfer order. The current status is highlighted. With appropriate privileges, you can use the
Workflow tab to promote the transfer order manually. This information also appears on the History
tab.

Attachments Tab
The Attachments tab of a CTO lists the files that have been attached to that transfer order. Attached
files can be drawings or scanned images, documents, non-viewable files, compressed files, and so
on. You can also point to a URL instead of a local attachment.

58 Agile Product Lifecycle Management


For more information about attachments and the Attachments tab, see Getting Started with Agile
PLM.

History Tab
The History tab shows a summary of actions taken against the transfer order, including:
 A description of the action
 Which user took the action
 The date and time of the action (local client time)
 Details of the action
 Comments made by users
 Users notified
 The current status of the transfer order
 The next status of the transfer order

While the transfer order status is Unassigned or Pending, the creation of the transfer order and any
subclass modifications are recorded on the History tab, but no other actions are recorded. A transfer
order must have a status type other than Unassigned or Pending before actions are recorded on the
History tab.

Comments on the History tab are different from the comments on the Workflow tab. Comments on
the Workflow tab come from approvers and observers during the online approval process.
Comments on the History tab can be made by anyone with sufficient privileges at any time.

The History tab shows some response information, such as the failure reason. In Java Client, you
can double-click a row in the History table to see detailed information.
Not e If you do not have the appropriate Read privileges, you cannot view the fields on the
History tab. If you have questions about your privileges, see your Agile PLM
administrator.

Creating Content Transfer Orders


If you have the appropriate privileges, you can create or modify a CTO.

Creating a CTO with the Create Command


When you create a CTO, you select the order type (subclass) and assign a number. Then you
complete it by entering data on its tabs.

In Java Client and Web Client, complete the fields on each tab.

For more information about creating transfer orders and other objects, see Getting Started with
Agile PLM.

v9.3.0.2 59
Not e Once the CTO is created, that CTO exists until you delete it. (See “Deleting Transfer
Orders”.)

Creating a CTO in Java Client


To create a CTO in Java Client:
1. Click the New Object button .
2. In the New dialog box, select the appropriate CTO subclass. Use the supplied autonumber, or
enter a number. Click OK.
The CTO is created and displayed with the Cover Page tab on top.
3. On the Cover Page tab, enter a description and select a workflow. The Default CTOs workflow is
recommended. When you have finished, click Save.
Not e The roles applied when object data is extracted are determined by the roles
assigned to the user listed in the Originator field on the Cover Page tab of the CTO.

For example, if the originator user does not have the necessary privileges to view items
assigned to the Libra product line, when BOM items are extracted, any product line Libra
items will be not be extracted.
In a similar manner, if the originator user is not assigned to the Hong Kong site, Hong
Kong BOM data will not be extracted, even if Hong Kong is selected in the Site column on
the Destinations tab.
4. On the Selected Content tab, click Add to search for objects you want to transfer. Select the
objects in the search results and click OK.
5. If any of the selected objects are items or prices, you must select a revision for each item or
price you have selected. In the Select Revisions dialog box, select an item in the left pane. In
the right pane, select the item revision you want. By default, the most recent released revision
is selected, but you may select a different revision.
When you have finished selecting revisions for each item, click OK. The objects are added to
the Selected Content table.

6. On the Where Sent tab, click Add to add a destination for the transfer. You can add multiple
destinations. (See Where Sent Tab.)
In the Add dialog box, select the following:
 From the Destination drop-down list, select a destination. Destinations are created and
defined by your Agile PLM administrator.

 In the Filters field, click the button to open the Filters dialog box. Select as many filters
as you need. Your Agile PLM administrator defines the filters used on your Agile PLM
system. If you have questions about which filters to use, ask your Agile PLM administrator.
You need at least one filter for each type of object type on the Selected Content table of
the CTO. On your Agile PLM system, there may be multiple filters for the same object
class, each with a different name and definition. Depending on how the filter is defined,
Agile ACS may extract only the table information visible on a tab, or Agile ACS may extract
the information visible in the table and also the objects listed in the table. For example, a
filter for items may include the option for the BOM tab of Tab and Items, All Levels. In this

60 Agile Product Lifecycle Management


example, when an item on the CTO Selected Content tab is extracted, all the items on its
BOM, through all BOM levels, are also extracted.
In a similar manner, a filter can determine whether the AML information on an item’s
Manufacturers tab is extracted. In that case, you must also select a filter for manufacturer
part objects and manufacturer objects.
Each type of object extracted needs a filter, whether the object type is listed on the Selected
Content tab of the CTO or the object type is referenced on the tabs of the selected objects.
For details about filters used in your Agile PLM system, ask your Agile PLM administrator.
 Select a data extraction format, either aXML or PDX. For details about these formats, see
Where Sent Tab.
Not e Refer to the export section of the Agile PLM Import and Export Guide for information
about which objects are supported in aXML or PDX.

 Select a language. For details about the language setting, see Where Sent Tab.
 In the Site field, select All, or select one site. For example, if you select the Hong Kong site,
only object data that is visible to the Hong Kong site will be extracted.
 When you are finished, click OK.

Creating a CTO in Web Client


To create a CTO in Web Client:
1. In the toolbar, choose Create New > Transfer Orders.
2. On the Create Content Transfer Orders page, select the appropriate CTO subclass. Use the
supplied autonumber, or enter a number. Click Save.
3. On the Cover Page Information tab, enter a description and select a workflow. The Default
CTOs workflow is recommended. When you have finished, click Save.
Not e The roles applied when object data is extracted are determined by the roles
assigned to the user listed in the Originator field on the Cover Page tab of the CTO.

For example, if the originator user does not have the necessary privileges to view items
assigned to the Libra product line, when BOM items are extracted, any product line Libra
items will be not be extracted.
In a similar manner, if the originator user does is not assigned to the Hong Kong site, Hong
Kong BOM data will not be extracted, even if Hong Kong is selected in the Site column on
the Destinations tab.
4. On the Selected Content tab, click Add to add the objects you want to transfer. In the Search
window, enter the search criteria for the objects you want to transfer, and click Search.
5. Double-click the objects you want to transfer. The objects are added to the Selected Content
table.
6. On the Add Where Sent tab, click Add to add a destination for the transfer. You can add
multiple destinations. (See Where Sent Tab.)
In the Add Transfer Specifications window, select the following:
 From the Destination drop-down list, select a destination. Destinations are created and
defined by your Agile PLM administrator.

v9.3.0.2 61
 In the Filters field, launch the palette to open the filter selection window. Select as many
filters as you need by double-clicking. Your Agile PLM administrator defines the filters used
on your Agile PLM system. If you have questions about which filters to use, ask your Agile
PLM administrator.
You need at least one filter for each type of object type on the Selected Content table of
the CTO. On your Agile PLM system, there may be multiple filters for the same object
class, each with a different name and definition. Depending on how the filter is defined,
Agile ACS may extract only the table information visible on a tab, or Agile ACS may extract
the information visible in the table and also the objects listed in the table. For example, a
filter for items may include the option for the BOM tab of Tab and Items, All Levels. In this
example, when an item on the CTO Selected Content tab is extracted, all the items on its
BOM, through all BOM levels, are also extracted.
In a similar manner, a filter can determine whether the AML information on an item’s
Manufacturers tab is extracted. In that case, you must also select a filter for manufacturer
part objects and manufacturer objects.
Each type of object extracted needs a filter, whether the object type is listed on the Selected
Content tab of the CTO or the object type is referenced on the tabs of the selected objects.
For details about filters used in your Agile PLM system, ask your Agile PLM administrator.
 Select a data extraction format, either aXML or PDX. For details about these formats, see
Where Sent Tab.
Note Refer to the export section of the Agile PLM Import and Export Guide for
information about which objects are supported in aXML or PDX.
 Select a language. For details about the language setting, see Where Sent Tab.
 In the Site field, select All, or select one site. For example, if you select the Hong Kong site,
only object data that is visible to the Hong Kong site will be extracted.
 When you are finished, click Add.

Creating a CTO Using the Save As Feature


Using the Save As feature is a quick way to create a new CTO that is very similar to an existing
CTO or ATO. This feature is also a good way to resend data previously sent in an ATO.
Not e If you do not have Discovery and Read privileges for any of the objects on the
Selected Content tab of the existing transfer order, an error message appears. You
can either cancel the CTO creation process or you can continue. If you choose to
continue, the CTO is created, however, on the Selected Content tab some objects
rows in the table are missing due to insufficient user privileges (no Discovery and
Read privileges for those objects). The missing objects are not extracted when the
CTO is processed.

Modifying Fields
With sufficient privileges, you can modify editable fields. You can modify only fields that have been
made editable by the Agile PLM administrator.

You cannot manually enter information on the Workflow or History tabs; Agile PLM automatically
completes these.

62 Agile Product Lifecycle Management


Not e After a CTO has reached the Released status, it is processed by Agile Content
Service, but you can still modify the Description field.

The CTO page opens with the Cover Page tab on top.
To modify a CTO in Java Client:
1. Complete or change the appropriate fields on the Cover Page tab. Click Save when you finish
editing the Cover Page tab.
2. On the Selected Content tab:

 To add objects, click the Add button , and follow the steps to search for and select the
objects you want.
 To remove objects, select and highlight the row you want to remove, and click the Remove
button .
 To select a different revision of an object, delete the object’s row and add the object again,
selecting a different revision.
3. On the Where Sent tab:

 To add destinations, click the Add button , complete the dialog box, and click OK.
 To edit a destination and its filters, click the row you want to select it, and click the Edit

button . In the dialog box, change the fields you want to edit, and click OK.
 To remove a destination, click the row you want to select it, and click the Remove button .

To modify a CTO in Web Client:


1. On the Cover Page tab, click Edit, and complete or change the appropriate fields. Click Save
when you finish editing the Cover Page tab.
2. On the Selected Content tab:
 To add objects, click Add, and follow the wizard steps to search for and select the objects
you want to add.
 To remove objects, check the rows of the objects you want to remove, and click Remove.
3. On the Where Sent tab:
 To add destinations, click Add. Complete the information in the window.
 To edit an existing destination, double-click the field on the row you want to edit, change
the value, and click Save.
 To remove destinations, check the rows of the destinations you want to remove, and click
Remove.

Deleting Transfer Orders


You can delete unreleased transfer orders. Agile PLM supports “soft” and “hard” deletes.
Not e You can undelete a soft-deleted object. You cannot undelete a hard deleted object.

You can delete only transfer orders that meet the following criteria:

v9.3.0.2 63
 You created it, or Agile PLM administrator has given you the appropriate privileges to delete a
transfer order.
 The transfer order is at the Pending status type or the Unassigned status.
 The transfer order has failed to reach its Destination.

Printing Transfer Order Tabs

In Java Client, click the Print drop-down list button and select All Tabs or select the tab you
want to print. The print preview dialog box opens. When you are ready, in the dialog box, click Print
.

In Web Client, you can print transfer order tabs from your Web browser. With the transfer order
open, choose Actions > Print. You can print the current tab or all tabs. Attachments are printed from
their native applications or the Agile Viewer.

For more information about printing, see Getting Started with Agile PLM.

Agile Standard Reports for Transfer Orders


For detailed information about using all types of Agile reports, see the “Working with Agile Reports”
chapter in Getting Started, which includes information about:
 Standard reports, custom reports, and external reports
 How your roles and privileges affect reports
 Report object tabs
 Creating and modifying report layouts
 Creating custom and external reports
 Running, scheduling, saving, and deleting reports
 Report output window

IP Transfer Report
The IP Transfer Report is the Agile standard report for transfer orders. This report lists the objects
sent to a given destination and when they were sent.

To run the IP Transfer report:


1. Select the IP Transfer report in the Reports > Standard Reports > Process Reports folder. The IP
Transfer Report page appears.
2. Click the Execute button. The Select Date Range and Destination page appears.
3. Select the start date and end date of the time period you want to the report to cover. This
defines the time range in which transfer orders were sent.

4. Click the Palette button next to the Destination field and double-click the destinations you
want to include.

64 Agile Product Lifecycle Management


5. Click Finish to display the report.

Default IP Transfer report layout fields Description

Object Number The number of the object that was sent, for example, an item number or
a change number.
Object Type The type (subclass) of object, for example, part type Resistor or change
order type ECO.
Description Description of the object that appears in the object’s Description field.
Date Sent The date the transfer order was processed and the object was sent to
the destination you selected in the report wizard.
TO Number The transfer order number.

v9.3.0.2 65
Chapter 11

Working with Packages


This chapter includes the following:

 What are Packages? ........................................................................................................................................... 67


 Intended Audience ............................................................................................................................................... 68
 Package License Requirements .......................................................................................................................... 68
 Who Uses Package Objects? .............................................................................................................................. 68
 Viewing Packages ............................................................................................................................................... 68
 Packages in Your Inbox ....................................................................................................................................... 72
 Package Workflow ............................................................................................................................................... 73
 Package Workflow Diagram ................................................................................................................................ 75
 Partners and Content Managers .......................................................................................................................... 77
 Creating a Package ............................................................................................................................................. 77
 Submitting a Package .......................................................................................................................................... 78
 Approving and Rejecting a Package .................................................................................................................... 78
 Importing Product Information from Package Attachments ................................................................................. 79
 Configuring Your Agile PLM System for Agile-to-Agile Communication .............................................................. 79
 About Searching for Packages ............................................................................................................................ 80
 Final Status of Packages ..................................................................................................................................... 80
 Deleting Packages ............................................................................................................................................... 80

What are Packages?


You can use packages to track, control, and route incoming product content.

Agile PLM packages may be created manually by supply chain partner users. More typically, Agile
Content Service (ACS) is used to initiate automatic Agile-to-Agile communication. Product data can
be sent to your Agile PLM system from another Agile PLM system. The target or receiving Agile
PLM system automatically creates a package object, attaches the data files, and submits the
package.

Product data can describe a proposed product. Product data may be files and documents attached
to the package object. However, ACS allows product data (Agile PLM objects) to be extracted into a
PDX or aXML file, which is attached to the package object. The PDX or aXML files can be imported
into the target or receiving Agile PLM system, thus creating the appropriate Agile PLM objects on
the target Agile PLM system. The files are accessed through the Attachments tab of the package.

Agile PLM packages are routable objects. They have workflows that determine the sequence of
statuses they follow as they go through the approval cycle.

A package is different from other Agile PLM objects because it has no relationship to any other
Agile PLM object. It does not have a revision level, you cannot write changes against it, it has no
Manufacturers tab, and it has no BOM.

In the same way that the change classes include the subclasses ECO, ECR, and MCO, the
Package class may include subclasses in addition to the out-of-the-box Package subclass if your
Agile PLM administrator has created them.

v9.3.0.2 67
If package attachments include PDX, aXML or comma-delimited text files describing Agile PLM
objects, the information can be imported directly from the Attachments tab of the released (accepted)
package once the package is released.

Intended Audience
This chapter assumes that you are a user who works with Agile PLM package objects. You may be
a user who creates and submits packages, an approver or an observer of packages that are routed
for approval, or a content manager, who is like a change analyst who works with packages. The
package objects you work with may be created by users who are supply chain partners, or the
package objects may be created automatically by Agile Content Service (ACS).

Package License Requirements


Agile PLM package objects allow any user, with the appropriate assigned privileges, to create, use,
and search for package objects.

Agile-to-Agile communication is provided by the ACS server license. The ACS license allows the
Agile PLM administrator to define the details of the automatic package object generation process.

Who Uses Package Objects?


Agile PLM packages are available to users with the appropriate roles and privileges. The content
manager uses Agile Java Client or Agile Web Client to oversee the routing and approval of
packages. Supply chain partners can create and submit packages or use Agile Content Service
(ACS) to submit them automatically.

ACS provides automatic Agile-to-Agile communication, which sends Agile PLM data from one Agile
PLM system to another. The destination or receiving Agile PLM system automatically creates
package objects that include the data files on the Attachments tab. The Agile PLM administrator of
the destination Agile PLM system defines the details of the automatic package object generation
process. Once the package object is automatically created and submitted, the approval and routing
procedures are the same as for any other routable object.

Viewing Packages
This section contains the following topics:
 Package Tabs
 Status of a Package

Package Tabs
Like any other Agile PLM object, a package object is displayed with tabs. This section contains the
following topics:
 Cover Page Tab
 Workflow Tab
 Attachments Tab

68 Agile Product Lifecycle Management


 History Tab

The following table lists the tabs for Agile PLM packages.
Package tab name Tab information includes

Cover Page General information about the package.


Source GUID, XFER Order Locator, and Response Expected are optional fields used by Agile
ACS.
Workflow Where the package is in the assigned workflow. Signoff approvers and observers, and the results
of their reviewing of the package.
Attachments Attached files. Content from PDX, aXML and CSV files can be imported from the Attachments
tab to the Agile PLM database.
For information about importing package attachment data into the Agile PLM database, see
Importing Product Information from Package Attachments.
History Shows actions taken on the package—for example, when attachments were added and
removed.

Not e Your Agile PLM administrator may have added additional Page Two and Page Three
tabs, which contain custom fields defined by the administrator.

Cover Page Tab


The package Cover Page tab includes some basic information about the proposed product. The files
and images describing the proposed product are included on the Attachments tab. The attachments
might include specifications, schematics, assembly drawings, test procedures, or any other file type
required. The content manager routes a package for review through workflow.
Cover Page field Completed Contains

Package Number Usually automatically; may be an autonumber or a Package number assigned to the package when
manually entered number. it is created.
Status Automatically, when created; updated as package The status of the package. See Status of a
moves through the assigned workflow. Package. If no workflow is selected, this field is
Unassigned.
Originator Usually manually, but may contain a default. The user who created the package (can be
selected from a drop-down list).
Partner Name Usually manually, but may contain a default. The partner (generally, a company) to which the
Originator is assigned.
Date Originated Usually automatically, when created (with default set The date the package was created.
by the Agile PLM administrator).
Date Released Automatically. Date the package was released, or accepted.
Assembly Number Manually. Number of the proposed assembly.
Assembly Manually. Revision of the proposed assembly.
Revision

v9.3.0.2 69
Cover Page field Completed Contains

Description Manually, but can contain a default defined by the Up to 1023 characters, including spaces and
Agile administrator. carriage returns (which count as two spaces).
ECO Number Manually. An ECO number associated with the assembly.
Package Type Usually manually, but may contain a default. Drop-down list of package types defined by the
Agile PLM administrator.
Program Manager Automatically when package changes from pending to Name of the content manager assigned to the
submit status. partner in the Partner Name field. A content
(may also be called
manager oversees the package routing process
Content Manager)
(similar to a change analyst).
Category Manually The category of this package. A package cannot
be changed to a Released workflow status
unless the Category field and all other required
fields have values.
Workflow Manually, whether one or more than one workflow The name of the workflow being used to move
applies. If more than one workflow applies to a the package through the approval process.
package, the workflow selection can be changed as
long as the package is in the Pending status type.
Selecting the blank field in the Workflow drop-down
list switches the package to the Unassigned status.
For more information about workflows, see Getting
Started with Agile PLM.
Final Complete Automatically. Date the package was switched to the Complete
Date status type.
Source GUID Automatically. Required for Agile Content Service (ACS) tasks.
Unique identifying code representing the source
Agile PLM system when a package object is
created by an Agile-to-Agile product content
transfer. If ACS is not being used, this field may
not be visible. See the Administrator Guide for
details.
XFER Order Automatically. Required for ACS tasks. Identifies the transfer
Locator order that created the package. If ACS is not
being used, this field may not be visible. See the
Administrator Guide for details.
Response Automatically. Required for ACS tasks. Indicates whether the
Expected source Agile PLM system expects a response
when the package is either accepted or
rejected. If ACS is not being used, this field may
not be visible. See the Administrator Guide for
details.

70 Agile Product Lifecycle Management


Workflow Tab
The Workflow tab displays a flowchart of the statuses in the selected workflow. The Signoff History
table on this tab lists the users who are assigned to either approve or observe the proposed
package, the actions taken by the approvers, the date and time of each action, and any comments
made by the approvers and observers. The Workflow tab of a package is identical to the Workflow tab
of a change.

Approvers and observers are automatically assigned by the workflow, or they are assigned when
the content manager routes the package for approval. For details, see the “Routing Objects with
Workflows” chapter in Getting Started with Agile PLM.

Attachments Tab
The Attachments tab lists the files and URLs that have been attached to the package. You can also
import data into your Agile PLM system from text, PDX, aXML, or .CSV files attached to the
package.

For general information about working with attachments, see Getting Started with Agile PLM.

For information about importing data from a package, see Importing Product Information from
Package Attachments.

History Tab
The History tab shows a summary of actions taken against the package, including a description of
the action, which user took the action, the current status of the package, the next status, and other
information.

The types of actions recorded on the History tab are:


 Modify an attachment on the Attachments tab
 Add or delete approvers
 Approve and reject
 Change a field, any tab
 Change a status
 Autopromotion fails
 Change a subclass
 Comments
 Send
 Print

Comments on the History tab are different from the comments on the Workflow tab. Comments on
the Workflow tab come from approvers and observers when they perform the online approval
process. Comments on the History tab can be made by anyone with sufficient privileges at any time.

v9.3.0.2 71
Status of a Package
Each package has a status stamp in the top right corner to indicate the status of a package. Your
Agile PLM administrator defines the name of each status in each workflow.

The following table shows the Default Packages workflow statuses.


Status name Status definition

Unassigned No workflow has been assigned to this package. The originator may still be developing the
package. No statuses are displayed on the Workflow tab.
(No status type)
Pending The originator may still be developing the package. The package has not been submitted to the
content manager.
(Pending status type)
Submitted The package has been submitted to the content manager. (If the content manager switches a
submitted package to the Pending status, the originator can modify the package and submit it
(Submit status type)
again.)
Review The package has been routed for review through workflow.
(Review status type)
Accepted The package has been signed off by the approvers and has been released.
(Released status type)
Closed The package is no longer used.
(Complete status type)
Hold The package has been placed on hold while the content manager gathers information.
(Hold status type)
Canceled The package has been canceled due to a fundamental flaw or because one or more approvers
have rejected it.
(Cancel status type)

Packages in Your Inbox


You can view packages that have been submitted to you in the Agile PLM Inbox.

To view packages in the Inbox in Java Client:


1. Click the Inbox drop-down arrow .
2. Choose Workflow Routings from the list.
3. In the Inbox table, click the Workflow column header to sort the table by workflows.

To view packages in the Inbox in Web Client:


1. From the Web Client toolbar, click Home to display the welcome page.
2. Click Workflow Routings to display your Workflow Routings Inbox.
3. In the table, click the Workflow column header to sort the table by workflows.

72 Agile Product Lifecycle Management


Package Workflow
Agile PLM packages may have custom workflows, just as changes may have custom workflows.
For details, see the “Routing Objects with Workflows” chapter in Getting Started with Agile PLM.

Packages are created by partners. Typically, partners are customers at other companies who use
Agile PLM to create packages.

Here is the typical workflow of a package:


1. A partner at another company creates an Agile PLM package.
2. When the package is complete, the partner submits it to the content manager.
3. The content manager opens and reviews the package. If the package data is not complete, the
content manager may return the package to the partner for more information.
4. If the package is complete, the content manager switches it to the next status in the workflow.
Typically, the next status is a Review status type, which routes the package for approval.
5. The approvers review the package and either accept it or reject it.
6. When the package is accepted by the approvers, depending on workflow settings, either the
content manager accepts (releases) it or it is autopromoted to the next status in the workflow
and released (accepted).
7. The content manager processes the package data according to unique company-specific
procedures.
If the package includes PDX files, aXML files, or comma-delimited text files describing Agile
PLM objects, these may be imported from the package Attachments tab. Package attachments
created by Agile-to-Agile communication (through Agile ACS) can be either PDX files or aXML
files.
a. On the package Attachments tab, select one attached file.
b. Click the Import button on the Attachments tab.
The import process begins.
c. Follow the onscreen instructions.
Not e For more information about the Import wizard, see the Import and Export Guide.

8. When the package is processed and no longer used, the content manager closes it.
Not e Your Agile PLM administrator may define custom workflows for packages. Custom
workflows may have multiple Submit, Review, and Released status types. For
details, see the “Routing Objects with Workflows” chapter in Getting Started with
Agile PLM.

The Package Workflow Diagram summarizes the typical workflow of an Agile PLM package, using
the Default Packages workflow.
Not e The content manager is the user named in the Program Manager field on the Cover
Page tab. Your Agile PLM administrator may have changed the name of this field.

v9.3.0.2 73
74 Agile Product Lifecycle Management
Package Workflow Diagram

v9.3.0.2 75
76 Agile Product Lifecycle Management
Partners and Content Managers
The Agile PLM administrator assigns the Partner role or Content Manager role to the appropriate
Agile PLM users.

What Is a Partner?
Partners are typically users at an EMS customer site who create Agile PLM packages of proposed
products and submit them to your company for review and approval. However, a user in your
company with the appropriate user license privileges may also create and submit packages.

What Is a Content Manager?


The Agile PLM administrator assigns specific partners to specific content managers. The role of a
content manager is similar to that of a change analyst or component engineer. Content managers
manage packages throughout their workflow. (In previous releases, the content manager was
referred to as the program manager.)

Creating a Package
To create a package, you must have the appropriate privileges.

Creating a Package Object in Java Client


You can create a package with the File > New > Package command or the File > Save As command.

The process for creating new objects involves two main steps: creating an empty object and then
filling in the object tabs with information specific to the object.

To create and complete a package:


1. Click the New Object button .
2. In the New dialog box, use the Type drop-down list to select the type (subclass) of package you
want to create.
3. Assign a number to the package. To do so, either use the supplied autonumber, click the
AutoNumber button , or type a number.
The autonumber format and sequence are determined by your Agile PLM administrator. Your
Agile PLM administrator also determines whether using autonumbers is required or optional.
4. Click OK.
The new package appears with the Cover Page tab showing.
5. Fill in information on the package tabs, as desired.

You do not enter information on the History tab. That tab is completed automatically.

Creating a Package Object in Web Client


You can create a package with the Create > New command or the Actions > Save As command.

v9.3.0.2 77
A wizard leads you through the process of creating a package and adding attachments.

To create and complete a package:


1. Choose Create New > Packages.
2. On the Create Packages page, select the appropriate Packages subclass. Use the supplied
autonumber, or enter a number. Click Save.
3. Complete the required information on each tab.
You do not enter information on the History tab. That tab is completed automatically.

When you click the AutoNumber button to enter the package number, you might see a list of
autonumber choices. The autonumber format and sequence are determined by your Agile PLM
administrator. Your Agile PLM administrator also determines whether using autonumbers is
required or optional.

Submitting a Package
You can submit an Agile PLM package using the same buttons and procedure you use to submit a
change or other routable object (provided you have the appropriate privileges). For details, see the
“Routing Objects with Workflows” chapter in Getting Started with Agile PLM.

No matter which Agile PLM product was used to create the package, when a partner submits a
package, the content manager is notified by email.

The content manager can also use defined searches in the Searches | Content Manager Searches folder
to find recently submitted packages.

Using the same buttons and selections used to work with changes, the content manager can
choose an action for the package, including:
 Audit the package.
 Return the package to the originator (partner) for more information.
 Route the package for review to a list of approvers and observers.
 Accept the package.
 Cancel the package.

See the Package Workflow Diagram for a summary of the default package workflow.

Approving and Rejecting a Package


Users on the approver and observer lists on the Workflow tab approve or reject a package the same
way they would approve or reject a change.

Approvers who do not respond to a package within the reminder period receive a reminder email,
telling them that they have not yet approved or rejected the package. If the approvers do not
respond within the review escalation period, then their appropriate designated escalation person
receives an email and can then accept or reject the package in the place of the original approvers.
For details, see the “Routing Objects with Workflows” chapter in Getting Started with Agile PLM.

78 Agile Product Lifecycle Management


Importing Product Information from Package Attachments
If a package contains PDX, aXML or CSV (comma-delimited text) files describing Agile PLM
objects, after the package is released (accepted), you can import the PDX, aXML or CSV
information directly into your Agile PLM database.

To import product information from package attachments:


1. Open the released package.
2. Display the Attachments tab.
3. Select a PDX, aXML or CSV attachment to import, and click Import. (You can import only one
attachment at a time.)
The Agile Web Client Import wizard opens, and the file you selected is specified as the file to
import. You cannot specify a different file at this point.

Follow the wizard steps to import the data. For more information about importing, see the Import
and Export Guide.

When the Import process is complete, you are returned to the Attachments tab of the package.

Configuring Your Agile PLM System for Agile-to-Agile


Communication
To successfully publish content data from one Agile PLM system (the source Agile System) to
another Agile PLM system (the target Agile System), the appropriate Agile Content Service settings
and process extension settings must be defined. It can be done only by the Agile PLM
administrator.

After Accepting/Rejecting Package Objects


In cases where Agile ACS is used to automatically perform Agile-to-Agile communication, the
source Agile PLM system can request a response from the target Agile PLM system. The required
settings are defined by the Agile PLM administrators of each system. Depending on the settings, a
response may be sent to the source Agile PLM system automatically (which requires no action on
your part), or you may be required to send a response manually.

If you are required to send a response manually, follow the instructions below.

To send accept or reject responses manually in Java Client:


1. Open the package.

2. Click the More button at the top of the object window to display the More Actions menu
and choose either Process Extensions > Accept Package Response or Process Extensions > Reject
Package Response.
Or, right-click in the window, and choose either Process Extensions > Accept Package Response or
Process Extensions > Reject Package Response from the shortcut menu.

v9.3.0.2 79
Not e The Process Extensions > Package Responses commands on the More Actions menu
and the shortcut menu are available only if your Agile PLM administrator has
enabled them.

To send accept or reject responses manually in the Web Client


1. Open the package.
2. From the Actions menu, choose either Accept Package Response or Reject Package Response.
Not e The Package Response commands on the Actions menu are available only if your Agile
PLM administrator has enabled them.

About Searching for Packages


If you have the appropriate privileges, you can search for Agile PLM packages the same way you
search for any object in the Agile PLM database. For details, see Getting Started with Agile PLM. If
you have questions about your privileges, see your Agile PLM administrator.

The Searches folder includes a Content Manager Searches folder, which contains the Packages
Submitted More Than X Hours Ago search and the CTOs Submitted More Than X Hours Ago
search.

Final Status of Packages


Once a package has been reviewed and approved by the approvers and accepted by the content
manager, the content manager can process the package data using the internal procedures specific
to your company. Also, the content manager can import the package data content from other Agile
PLM systems from the package object Attachments tab by using the Import button. (See Importing
Product Information from Package Attachments.) For example, the attachments on the package
Attachments tab may become attachments for Agile PLM items in your Agile PLM database, or
attachments that are PDX, aXML or CSV files could be imported into your Agile PLM database.

The procedures used to process package data are unique to each company. Ask your Agile PLM
administrator or your system administrator for information about how this task is performed at your
company.

When you have completed processing the package, the content manager can change its workflow
status to the Closed status type by using either the Next Status button or Workflow tab.

Deleting Packages
Agile Java Client and Web Client support “soft” and “hard” deletes.

Caution You cannot undelete a hard-deleted object.

You can delete packages that meet the following criteria:


 You created it; or you are the content manager, and your Agile PLM administrator has given
content managers the appropriate privileges to delete a package.
 The package is at the Pending status type or the Unassigned status.

80 Agile Product Lifecycle Management


To soft-delete an unreleased package in Java Client:
1. Open the package that you want to delete.

2. Click the Delete button in the package object window, and respond Yes to the confirmation
prompt.

The package is soft-deleted. It is no longer available for use. However, until it is hard-deleted, its
number is reserved and cannot be reused.

To soft-delete an unreleased package in Web Client:


1. Open the package that you want to delete.
2. Choose Actions > Delete, and respond OK to the confirmation prompt.

The package is soft-deleted. It is no longer available for use. However, until it is hard-deleted, its
number is reserved and cannot be reused.

To hard-delete a soft-deleted package in Java Client (if you have the appropriate privileges):
1. From the Recycle Bin Searches folder, run the Deleted Packages search to locate the soft-
deleted package you want to hard-delete.
2. Open the package.

3. Click the Delete button in the package object window, and respond Yes to the confirmation
prompt.

To hard-delete a soft-deleted package in Web Client (if you have the appropriate privileges):
1. From the Recycle Bin Searches folder, run the Deleted Packages search to locate the soft-
deleted package you want to hard-delete.
2. Open the package.
3. Choose Actions > Delete, and respond OK to the confirmation prompt.

Undeleting Packages
Since soft-deleted packages still exist in the database, you can undelete them if you have the
necessary privilege. You can undelete packages associated with partners to which you are
assigned.

To undelete a package in Java Client:


1. Find the soft-deleted package by running the Deleted Packages search in the Recycle Bin
Searches folder.
2. Open the deleted package you want to restore.
3. To undelete the package, choose Edit > Undelete.

The previously soft-deleted package is undeleted and is once more available to users.

To undelete a package in Web Client:


1. Find the soft-deleted package by running the Deleted Packages search in the Recycle Bin

v9.3.0.2 81
Searches folder.
2. Open the deleted package you want to restore.
3. To undelete the package, choose Actions > Undelete.

The previously soft-deleted package is undeleted and is once more available to users.

82 Agile Product Lifecycle Management

You might also like