e-Tendering ebXML Standards Trial Implementation Verification Report

1
e-Tendering ebXML Standards Trial Implementation
Verification Report
2
Contents

• How to verify
• Development of Systems
• Conclusion

3
Policy of this verification

• The current target technology solution of
  e-Tendering ebXML Standards is XML Schema and
  XML.
• But HTML is more popular than XML and there're
  much more web systems than XML systems in the
  world.
• Therefore HTML is used as target technology
  solution and web systems are designed
  implementing the standards.
• To verify the technical validity, the systems are
  compared to the current running system.

4
How to verify

• The verification takes steps as follows
• making rules to design HTML based on the
  standards.
• designing system flows according to the rules
  based on Activity Diagrams.
• designing web pages according to the rules based
  on Business Document Class Diagrams and BIE
  table.
• comparing specifications including these flows
  and pages of the web system to those of current
  running systems.

5
Rules for designing HTML (1/12)

• R1 Business Document is developed on HTML and
  exchanged between web system and web browser by
  HTTP.
• On Business Transaction, One actor is mapped to
  web system and the other actor is mapped to web
  browser.

6
Rules for designing HTML (2/12)

• R2 Business Documents and BIEs included in
  them which sent from one actor mapped to web
  system to the other actor mapped to web browser
  are mapped to HTML files sent by HTTP Response
  message.

7
Rules for designing HTML (3/12)

• R3 Business Documents and BIEs included in
  them which sent from the other actor mapped to
  web browser to one actor mapped to web system are
  mapped to information sent by HTTP Request
  message with HTTP Method GET or POST such as
  the result of submitting a form.

8
Rules for designing HTML (4/12)

• R4 Business Transactions which is required a
  response (i.e. Commercial Transaction, Request
  Response, Query Response, Request Confirm) are
  mapped as follows

RequestingRole Web Browser
RespondingRole Web System
RequestingRole Web System
RespondingRole Web Browser
Document Request
Document Request
Document Response
Document Response
Transaction starting from actor mapped to web
system
Transaction starting from actor mapped to web
browser
9
Rules for designing HTML (5/12)

• R5 Business Transactions which are not
  required a response (i.e. Information
  Distribution, Notification) are mapped as follows

RequestingRole Web Browser
RequestingRole Web System
RespondingRole Web System
RespondingRole Web Browser
Document Request
Document Request
Transaction starting from actor mapped to web
browser
Transaction starting from actor mapped to web
system
10
Rules for designing HTML (6/12)

• R6 Addition of HTML files or information which
  are not mapped to Business Documents may be used.
• R7 A Business Document may to be divided into
  a series of HTML files or information. The status
  of sending them should be controlled not to
  violate that of Business Transaction, in case
  accessing the middle of the series direct or
  interrupting to send in the middle of the series.

11
Rules for designing HTML (7/12)

• R8 A Business Document should be sent by only
  1 series of HTML files or information.
• R9 HTML files may add decorations.

12
Rules for designing HTML (8/12)

• R10 Mandatory BIE included in a Business
  Document should be included in the series of HTML
  files or information which implements the
  Business Document. Optional BIE included in a
  Business Document may be chosen to include or not
  in them by business needs.
• R11 Information included in HTML files for
  confirmation sent by HTTP Response may be treated
  that its included in the next HTTP Request rose
  in the response.

13
Rules for designing HTML (9/12)

• R12 In case there are some branches in a
  series, mandatory BIE should be sent in any
  branches chosen.
• R13 The number of information in a series is
  must be lower than the max cardinality of BIE
  which the information based on.

14
Rules for designing HTML (10/12)

• R14 The order of sending information is
  optional in a series.
• R15 Visibility of information in HTML files
  may be chosen by business needs. In case
  information is not needed even if BIE based on it
  is mandatory in the Business Document, it is
  allowed to be invisible in a series of HTML files.

15
Rules for designing HTML (11/12)

• R16 Business Transaction may be implemented to
  send same Business Document in many times when it
  is requested.
• In case sending a series of HTML files or
  information is finished, the status of a Business
  Collaboration including the Business Transaction
  is not needed to go next automatically. The
  status of proceeding it should be controlled not
  to violate that of Business Collaboration.

16
Rules for designing HTML (12/12)

• R17 Business Collaboration may be implemented
  to proceed concurrently.
• In case Business Process is defined
  sequentially, it provides the order of starting,
  but the order of finishing may be changed. The
  status of proceeding it should be controlled not
  to violate that of Business Process.

17
Development of systems

• The specification of the system implementing the
  standard is developed to compare to existing
  systems as follows
• The Electronic Tender and Examine System of
  Japanese Ministry of Internal Affairs and
  Communications (MIAC)
• The Core System of Japan Construction Information
  Center (JACIC)

18
Implementation of the standards

• e-Tendering ebXML Standard is implemented as
  Procuring Entity is mapped to web system and
  Tenderers are mapped to web browsers.
• Business Document Class Diagrams submitted from
  Tenderers to Procuring Entity (i.e. Tender) are
  mapped to information sent as HTTP Request
  message with HTTP Method GET or POST such as the
  result of submitting a form and so on.
• And those sent reversely (i.e. Tender Result
  Notice) are mapped to information sent as HTTP
  Response message.

19
The Electronic Tender and Examine System (ETES)
of MIAC

• developed and hosted by Japanese Ministry of
  Internal Affairs and Communications (MIAC).
• reference system for tendering goods and services
  in Japan.

20
ETES Systems Architecture
21
ETES System Flow

• Overall flow

22
ETES Page flows

• i.e. Registration Application

RequestingRole Tenderer
RespondingRole Procuring Entity
Document Request Registration Application
Document Response Reception of Registration
Application
23
ETES Web pages
24
ETES Comparison

• i.e. Tender

BBIE Bid_ Price. Charge. Amount
BBIE Tender_ Document. Bill of Quantities_
Attachment. Binary Object
25
The Electronic Bidding Core System of JACIC

• developed by Electronic Bidding Core System
  Development Consortium. The Consortium is
  organized by the Japan Construction Information
  Center (JACIC) and the Service Center of Port
  Engineering (SCOPE) .
• http//www.cals.jacic.or.jp/english/coreconso/
• reference tendering system for Construction
  Domain in Japan.

26
Core System System Architecture
27
Core System System Flow
28
Core System Page Design
Tender Document
29
Core System Screen Images
Invitation To Tender
Invitation To Tender
Tender
Qualification Result Notice
30
Comparison Test Business process
Supplier Function
Procuring Entity Function
Same Actor
Send Tender Document Statement or Refusal Notice
Store Tender Document and Statement Send
Reception of Tender document
Tender Document
Statement
Tender Receipt Period
Send Reception of Tender document
Same Document
Same direction
Receipt Reception of Tender document
Business Transaction Activity Diagram (UN/CEFACT
Standard)
Protocol Diagram (Core System)
31
Comparison Test BIEs
Qualification Application Form (UN/CEFACT
Standard)
Qualification Application Form (Core System)
32
Conclusion

• 2 Trial implementation verifications are finished
  in Japan.
• Trial Implementation Verification Reports are
  submitted to UN/CEFACT.
• Please see the reports, if having interests.