9 Settings Required for Agile-To-Agile Publishing

This chapter includes the following:

Defining Settings for Agile-To-Agile Publishing
Verifying Agile-to-Agile Publishing

9.1 Defining Settings for Agile-To-Agile Publishing

To successfully publish content data from a source Agile PLM system to another target Agile PLM system, you must define the necessary Agile Content Service settings and process extension settings. 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.

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.

9.2 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:

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 13.)

Note:

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.

Create a package object. Use the package subclass specified in the target Agile PLM system package service.
Delete the package object. This verifies that the user has the necessary privilege to delete the package object.
Create another package object. Use the package subclass specified in the target Agile PLM system package service.
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.)
Click Save.
Click the Attachments tab to display it.
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, for example, a simple text file.
Click the Workflow tab to display it.

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 41.)

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

Note:

The Default Packages workflow and the Agile-supplied Partner role (modified as explained in Setting and Editing Package Services on page 41) 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 system, on the Where Sent tab of the ATO, the error "Insufficient Privilege" appears.	The target Agile PLM system user specified as the login user in the Agile PLM source system destination does not have the necessary privileges to either create a package 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 system, modify the role of the login user to one that has the necessary privileges. See Setting and Editing Response Services on page 45.
In the target Agile PLM system, the package object is created, but does not move to the correct workflow status; the error "Insufficient Privilege" appears.	If the login user on the target Agile PLM system has the necessary privileges (see row above), then the package workflow on the target system may not allow the package to move directly to the workflow status specified in the package service.	If the login user has the necessary change status privileges (see row above), verify that the package workflow (on the target system) you are using allows a status change directly from the Pending Type status to the 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 appear on the target Agile PLM system.	If the package object on the target system cannot be moved to the workflow status specified in the package service (for any reason, including, but not limited to, insufficient login user privileges), the target Agile PLM system attempts to delete the package object. If the login user does not have the appropriate Delete privilege mask, this may fail, and thus it is possible to have duplicate package objects.	In the target Agile PLM system, verify that the login user has a role that includes a Delete privilege mask for package objects. If not, modify the role or assign an appropriate role. Also verify that the login user has a role with the necessary privileges to move the package object to the workflow status specified in the package service. See Setting and Editing Response Services on page 45.