| Agile Product Lifecycle Management ACS User Guide Release 9.3.5 E61165-01 |
|
 Previous |
 Next |
This chapter includes the following:
Overview
Creating Response Services
Editing Response Services
Deleting Response Services
Understanding Responses and Process Extensions
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. Also, define from the Workflows node, which package workflow status initiates a response. The response is sent and managed from the Response Services node. See "Understanding Responses and Process Extensions."
|
Note: Package Services and Response Services are defined on an Agile PLM system that receives Agile-to-Agile data. See Chapter 9, "Settings Required for Agile-To-Agile Publishing." |
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.
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:
Under System Settings > Agile Content Service, double-click Response Services. The Response Services window appears.
Click the New button. The Create Response Service dialog box appears.
Type the name and description of the destination in the Name and Description fields.
Select HTTP or HTTPS from the Server URL drop-down list.
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
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.
Type the username and password of the source Agile PLM application server in the Username and Password fields.
Click Retrieve GUID to verify the destination.
If the destination is verified, the GUID field is completed automatically.
Click OK.
You can edit all of the parameters of the response service.
To edit a response service:
Under System Settings > Agile Content Service, double-click Response Services. The Response Services window appears.
Double-click the response service you want to edit.
Edit the General Information tab make the necessary changes.
|
Note: If you change the Server URL, Username, or Password field, click Retrieve Response Service to automatically verify and update the GUID field. |
Click Save and Close.
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.
|
Note: 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:
Under System Settings > Agile Content Service, double-click Response Services. The Response Services window appears.
Select the response service you want to delete.
Click the Delete Button to put text here
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.
