How to Create or Edit a Process Configuration
This topic describes how to create or edit a process configuration.
The settings in the process configuration are as shown in the following table, arranged by tab. Procedures for creating and editing a process configuration appear after the table.
The authorization and non-repudiation properties are interdependent. For more information about how to set these properties, see Authorization and Non-Repudiation Properties.
| Tab | Setting | Usage |
|---|---|---|
| General | Display Code | The Partner Interface Process (PIP) display code. This can correspond either to the RosettaNet PIP designation or to the name for a custom schema. It is recommended that you use a standard naming convention, such as a name including the process code and the version, for example, "STD_3A2_R02.00.00A". This will make it easier for you to maintain different versions of the same PIP. Required field. |
| General | Process Code | The three-digit PIP code. For example, "3A2". Required field. |
| General | Version | The version of the PIP. For example, "V02.02" or "R02.00.00A". Required field. |
| General | Process Name | The name of the PIP. For example, "Price and Availability Request Action". Required field. |
| General | Description | A description of the messages that conform to the PIP. |
| General | Standard | The type of standard. Possible values: RosettaNet (the default) or CIDX |
| General (Non-RosettaNet content area) |
Message standard | For non-RosettaNet content, the name of the non-RosettaNet standard. Use this setting if you are not using a RosettaNet PIP, but have defined a custom schema. Use this setting for RNIF 2.0 only, not for RNIF 1.1 or CIDX. |
| General (Non-RosettaNet content area) |
Standard version | For non-RosettaNet content, the version of the non-RosettaNet standard. Use this setting if you are not using a RosettaNet PIP, but have defined a custom schema. Use this setting for RNIF 2.0 only, not for RNIF 1.1 or CIDX. |
| General (Non-RosettaNet content area) |
Payload binding ID | For non-RosettaNet content, the identification number of the payload content. Use this setting if you are not using a RosettaNet PIP, but have defined a custom schema. The party implementing the custom PIP should define this value. Use this setting for RNIF 2.0 only, not for RNIF 1.1 or CIDX. |
| Activity (Acknowledgement of Receipt area) |
Non-Repudiation Required | Determines whether signal messages must be signed (with a message digest included in the acknowledgement message) and stored in their original form by the receiving party in the MessageStorageIn or MessageStorageOut table of the BTARNArchive database, for non-repudiation purposes. The receiving party must store the signals for the period designated in the Non-Repudiation of origin property in the partner configuration. Possible values: True (the default) or FalseIf False, signal messages will not be stored for non-repudiation purposes. Signal messages can be signed or not.If True, inbound signal messages will be stored in their original form in the MessageStorageIn table. Outbound signal messages will be stored in their original form in the MessageStorageOut table. Signal messages must be signed.For more information, see Authorization and Non-Repudiation Properties. |
| Activity (Acknowledgement of Receipt area) |
Time To Acknowledge (seconds) | The time in seconds by which the initiator must receive the acknowledgement. If the initiator does not receive it by this time, the initiator will retry if the retries have not exceeded the Retry count (in the Behavior section of this tab). BTARN measures the Time To Acknowledge value from the time the initiator sent out the action message successfully. The value is included in the delivery header. The value cannot be less than zero or greater than the Time To Perform value that is set on the same page. You use this setting for signal messages (application acknowledgements) returned in RNIF 1.1 and 2.01 processing. You also use this setting for acceptance acknowledgements returned in RNIF 1.1 processing. The default value is 7200 seconds (two hours). |
| Activity (Behavior area) |
Is Authorization Required | Determines whether any incoming Action or Signal message must be signed. BTARN will not accept a business document if the individual/role is not authorized to perform the activity. Possible values: True (the default) or FalseIf False, outbound action and signal messages will not be signed. Inbound action and signal messages may be signed. If they are not signed, the system will authorize the partner using the delivery header.If True, incoming messages must be signed. Outgoing messages may be signed. Outgoing messages are signed only if Non-Repudiation of Origin and Content is set to True.For more information, see Authorization and Non-Repudiation Properties. |
| Activity (Behavior area) |
Is Persistent Confidentiality Required | Determines whether encryption is required. Possible values: None (the default) indicates that no encryption is required. Payload indicates that encryption of the service content and attachments is required. Payload Container indicates that encryption of the service content, attachments, and service header is required. In RNIF 2.0, the preamble and delivery header are never encrypted. In RNIF 1.1, no message parts are encrypted. They are only signed. |
| Activity (Behavior area) |
Is Secure Transport Required | Determines whether HTTPS transport is required. Possible values: True (the default) or False |
| Activity (Behavior area) |
Is Single Action | Determines whether messages are single-action or double-action. Possible values: True (the default) or FalseSingle-action messages are Information Distribution or Notification. Double-action messages are Business Transaction, Request Confirm, Request/Response, or Query/Response. If the standard is CIDX, Is Single Action must be True. |
| Activity (Behavior area) |
Is Synchronous | Determines whether trading partners will exchange action messages synchronously or asynchronously. Possible values: True or False(the default)Not used for RNIF 1.1. |
| Activity (Behavior area) |
Non-Repudiation of Origin and Content | Determines whether action messages must be signed and stored by the receiving party in their original received form in the MessageStorageIn or MessageStorageOut table of the BTARNArchive database, for non-repudiation purposes. The receiving party must store the action messages for the period designated in the Non-Repudiation of origin property in the partner configuration for non-repudiation purposes. If required, the action messages must be signed. Possible values: True (the default) or FalseIf False, action messages will not be stored for non-repudiation purposes. Action messages can be signed or not.If True, inbound action messages will be stored in their original form in the MessageStorageIn table. Outbound action messages will be stored in their original form in the MessageStorageOut table. Action messages must be signed.For more information, see Authorization and Non-Repudiation Properties. |
| Activity (Behavior area) |
Retry Count | The number of times that the process should retry the activity if transport or processing fails. If the retry count is 3, then the process will attempt the activity four times. The default value is 3. If communication is synchronous, then BTARN does not use this field, because retries do not apply in synchronous transactions. |
| Activity (Behavior area) |
Time to Perform | The period (in seconds) within which the process must complete the activity. The period begins when the initiator sends the first document. The initiator (not the responder) must make sure that the activity completes within this period. This value is in the delivery header. The default value is 86400 seconds (24 hours). The Time To Perform value must be greater than the Time To Acknowledge value that is set in the Acknowledgement of Receipt section of the same page. |
| Activity (General area) |
Type | Determines the type of the activity. Possible values: Business Transaction, Information Distribution (the default), Notification, Query/Response, Request/Confirm, or Request/Response |
| Initiator (Business Document area) |
Description | A description of the initiator action's business document. |
| Initiator (Business Document area) |
Name | The name of the initiator action's business document. For example, "Price and Availability Request". |
| Initiator (Business Document area) |
Version | The version of the business document. For example, "V02_02_00" or "R02.00.00A". You can find this version number at the beginning of the RosettaNet XML Message Guidelines .htm file that you download with the PIP specification .doc file and the PIP DTD from the RosettaNet organization. |
| Initiator (General area) |
Action | A description of the initiator action. For example, "Synchronous Test Query Action". |
| Initiator (General area) |
Role | The role of the initiator. For example, "Buyer" or "Payer". The default value is "Initiator". |
| Initiator (General area) |
Role Description | A description of the role of the initiator. For example, "The party issuing the payment". |
| Initiator (General area) |
Role Type | The type of role of the initiator. Possible values: Organizational, Employee, or Functional (the default) |
| Initiator (General area) |
Service | The initiator service. For example, "Buyer Service" or "Payer Service". |
| Initiator (General area) |
Service Classification | The type of initiator service. For example, "Business Service". |
| Responder (Business Document area) |
Description | A description of the responder action's business document. For example, "Formally confirms the status of line items in a purchase order". |
| Responder (Business Document area) |
Name | The name of the responder action's business document. For example, "Purchase Order Confirmation". |
| Responder (Business Document area) |
Version | The version of the business document. For example, "V02.02.00" or "R02.00.00A". You can find this version number at the beginning of the RosettaNet XML Message Guidelines .htm file that you download with the PIP specification .doc file and the PIP DTD from the RosettaNet organization. |
| Responder (General area) |
Action | A description of the responder action. For example, "Purchase Order Confirmation Action". |
| Responder (General area) |
Role | The role of the responder. For example, "Seller". The default value is "Responder". |
| Responder (General area) |
Role Description | A description of the role of the responder. For example, "The party receiving payment". |
| Responder (General area) |
Role Type | The type of role of the responder. Possible values: Organizational (the default), Employee, or Functional |
| Responder (General area) |
Service | The responder service. For example, "Seller Service". |
| Responder (General area) |
Service Classification | The type of responder service. For example, "Business Service". |
To implement a new process configuration
Click Start, point to All Programs, point to Microsoft BizTalk Accelerator for RosettaNet, and then click BizTalk Accelerator for RosettaNet Management Console.
In the BTARN Management Console, expand BizTalk Accelerator for RosettaNet.
Right-click Process Configuration Settings, point to New, and then click Process Configuration.
In the New Process Configuration Properties dialog box, on the General, Activity, Initiator, and Responder tabs, type values for the settings listed in the preceding table, and then click OK.
To edit a process configuration
Click Start, point to All Programs, point to Microsoft BizTalk Accelerator for RosettaNet, and then click BizTalk Accelerator for RosettaNet Management Console.
In the BTARN Management Console, expand BizTalk Accelerator for RosettaNet.
Click Process Configuration Settings.
Right-click the process configuration that you want to edit, and then click Properties.
In the <process configuration> Properties dialog box, on the General and Contact Properties tabs, change the settings as required. For information about these settings, see the preceding table.
Click OK.
See Also
Using the PIP Specification to Create a Process Configuration
Authorization and Non-Repudiation Properties
Setting Up CIDX eStandards Message Exchange
Administering the BTARN Configuration
Feedback
Kommer snart: Under hela 2024 kommer vi att fasa ut GitHub-problem som feedbackmekanism för innehåll och ersätta det med ett nytt feedbacksystem. Mer information finns i: https://aka.ms/ContentUserFeedback.
Skicka och visa feedback för