DesignFest Home

NetDoc

Network Document Distribution Service

[ Home | Problem Collection | Results for this problem | Implementation for this problem ]

Prepared by

Gail E. Harris (Deloitte & Touche Consulting Group/DRT Systems)

Domain

Program Specification

Detailed Requirements

Use Cases

Domain

The ABC company supplies widgets and services through a network of Value Added Resellers (VARs). The CEO of ABC wants to improve their marketshare by reducing the time it takes to provide a standard contract to a VAR. She envisions a Web based application on their corporate Web site where VARs can log in to a secure connection, and provide information about products and services it is selling to a particular client. The application will then prepare a standard contract appropriate to the circumstances described and transmit the contract in a relatively secure format to the VAR. The transmission of the data and the transmission of the contract should all take a few seconds, on average.

Program Specification

The Technical Architect for the NDDS project prepared the following architectural overview for the system:

A user of the NDDS expects the following behaviour:

  1. The client application, represented by a web browser in the diagram, opens a web browser to pull up a contract request form from the secure web site.  He/she then enters the details of the products and services to be provided and the contract identification number, and chooses the documents for the contract to be generated.
  2. The Web server forwards the contract request to the NDDS.
  3. The NDDS then extracts the information from the request and retrieves the required contract templates and the specific data that needs to be merged from a database.  The system then merges the data with the contract template to form an actual contract.  The system will also save a copy of the contract (in PDF format) for later comparison.  It sends a copy back to the client browser.
  4. When the client gets the document back at the browser, he/she prints out a hard copy and has it signed by the customer.
  5. The original signed documents are faxed back to the company for archiving as legal contracts.
The only part of the system that needs to be written is the component that generates the contract by merging the data into the PDF template to create an actual contract, that is, Step 3 above. Somebody has already written a utility to create contract templates in the appropriate .PDF format. The architecture uses a third party product pdfFusion, a plug in to Adobe Acrobat, that has a script language for setting values of fields in the contract templates created through the above utility.

The contract generation component of the NDDS system is based on the use of an Application Server.  Access to the document generation service from the client browser is managed through the Application Server.

Detailed Requirements

The following steps describe the typical contract generation process:
  1. The client application (in this case, a browser) sends a request to Oracle Web Application Server.  The request contains the User ID, Application ID and Document ID .
  2. The Application Server executes an application, which does the following:

    3. – retrieves the contract data in the form of an XML file or XML data stream
    – retrieves the appropriate contract template (in PDF format) from template storage
    – maps the names of the template fields that need to be filled in to their XML tag names
    – looks up the corresponding values of these XML tags in the XML file or data stream
    – creates a script file (*.pff) with the required pdfFusion tag name/tag value pair and puts it in a “watch
       folder”
    – blocks itself until the desired output file (completed lease document) appears in the output file
  3. pdfFusion picks up the script file from the “watch folder” and performs document merging based on the scripts.  The output file (completed contract document in PDF format) is put into a designated output folder.
  4. Once the output file appears in the output folder, the component unblocks itself.
  5. The Application Server then returns the URL of the completed lease (PDF file) and the return code to the calling application (in this case a browser).
  6. When the user clicks on the link on the client browser , the PDF file will be downloaded to the client machine.


Your job is to design the Contract Generation component.

Use Cases

  1. An organisation using a standard web browser requests a lease contract over the Internet. This either returns a valid XML stream with a tag indicating the URL for the generated document or with the return code indicating an error. Some possible errors are: invalid parameter in the request, template could not be found, the pdfFusion process is not available, or the pdfFusion process had a time out.
  2. A blank document is requested.
Last updated by Torsten Layda,SWX Swiss Exchange, DesignFest® Webmaster.