Clickable Business Models eBusiness Education Acronyms Cross References
B2B Content Standards EC Technology Standards Glossary Implementation Guidelines
Implementation Options General Recommendations References Methodology/Legends
 Home | Copyright Notice and Legal Disclaimers | Navigation Help | Tour! | Downloads | Contact Us | Site Index | Search
Implementation Options | Technical Basics | Internet Commerce Model  | Architecture |
Implementation (Technology) Options

Implementation Option 3c (RosettaNet PTP) - How It Works:  Run Time, Outbound
 
Special Notes:  

 
Data Extraction from Application
Transmit to Gateway
Identify File
   Map and Validate or Pass-thru
   Envelope for Transmission
Transfer to HTTPS Server
Log Transmission Data
Transfer to Trading Partner's HTTPS Server
Monitor for Receipt Acknowledgment
Back to Implementation Option 3c Index

 

  1. Data is extracted from your application data base, using application integration software, typically into an interface file, usually a proprietary, flat-file format.  Some applications extract data into one or more standard formats.  The file must contain some identifier that the gateway will use to know how to process the file.
  1. If the application and the gateway are on different machines, an internal communications network is used to transmit the application data file to the gateway.
  1. The gateway uses the identifier in the application file to retrieve information about what to do with the application file.
  1. Whether the file should be pass-thru or mapped into another format.  The most typical case is that an interface file is translated from an internal format into into the RosettaNet XML standard standard.
  1. RNIF specifies how the file should be enveloped and transported, including how to identify the sender, the receiver, the data content standard and version, the type of message contained in the file, and assigning control numbers.
  1. A RosettaNet Business Message consists of a Preamble, a Delivery Header, a Service Header, Service Contents (the actual business document), and optional attachments.
    1. The service content and optional attachments are created per the PIP specification.
    2. The service header is created and contains information about the PIP, its service content and any attachments.
    3. The delivery header is created and contains sender and receiver IDs and message tracking ID.
    4. The preamble is created.
  2. The parts just listed are packaged.  The rules for packaging are specified in RNIF, and the steps for packaging depend on whether or not encryption is used, and whether the encryption applies to payload only or payload plus service header.  If encryption is used, the encryption is done during the packaging.
  3. If digital signatures are used, the signature is created and attached.
  1. The gateway transfers the PIP to an HTTPS (web) server.
  1. The gateway logs information about the transaction, including date and time sent.  If a receipt acknowledgment (RNIF 1.1 or RNIF 2.0) is expected from the recipient, the gateway sets a status flag so indicating, time the transmission was sent, and a time when a receipt acknowledgment is expected, based on a parameter set during implementation that indicates that a receipt acknowledgment is expected within n hours of the time of transmission.
    1. A receipt acknowledgement is required for most RosettaNet PIP messages.  A few PIPs use a query/response interaction pattern that does not use receipt acknowledgments.
  1. From the HTTPS server, an internet communications script executes the communications connection script and deposits data into your trading partner's HTTPS server.
    1. The connection is secure HTTPS (HTTP over SSL) or SMTP.  Trading partners are responsible for verifiying identity and entitlement to services, and ensuring that security requirements for privacy, authentication, data integrity and non-repudiation are met and are compliant with RNIF.
  1. The gateway monitors all transactions for which a receipt acknowledgment is expected and where a substantive response (response business document is required).
    1. One-way notification/distribution PIP (only one business document in one direction):
      1. If a receipt acknowledgement is received within the configured amount of time, the PIP is "closed" as far as the gateway is concerned.  This has no relationship to the status of the business information in the back-end systems; it is merely the status of the transmission.
      2. If a receipt acknowledgment is not received within the configured amount of time, and a retry-count is specified in the PIP, then the Business Message is resent automatically.  If the number of allowable retries has been exhausted, and the receipt acknowledgment is still not received, the gateway should launch PIP 01A, Notification of Failure.  If PIP 01A fails, manual intervention is required to resolve the situation.
    2. Two way request/response PIP (a request business document in one direction and a response document in the opposite direction):
      1. If a receipt acknowledgement is received within the configured amount of time, the request action part of the PIP is "closed" as far as the gateway is concerned.
      2. If a receipt acknowledgment is not received within the configured amount of time, and a retry-count is specified in the PIP, then the Business Message is resent automatically.  If the number of allowable retries has been exhausted, and the receipt acknowledgment is still not received, the gateway should launch PIP 01A, Notification of Failure.  If PIP 01A fails, manual intervention is required to resolve the situation.  The PIP state need to be manually adjusted in the gateway.
      3. If a substantive acknowledgment is received within the configured amount of time, the PIP is "closed" as far as the gateway is concerned.  This has no relationship to the status of the business information in the back-end systems; it is merely the status of the public process.
      4. If a substantive acknowledgment is not received within the configured amount of time, the gateway should launch PIP01A, Notification of Failure.  The PIP may need to be manually "closed" in the gateway.
      5. If the substantive acknowledgment is received before the receipt acknowledgment, the processing is not complete.  Even though the substantive acknowledgment tells you that the the Business Message was received, the receipt acknowledgment is still needed for non-repudiation.  The gateway should allow for this potential out-of-sequence processing.

 


 

Last updated 02 March 2003