cen/isss ebif gtib project meeting, brussels mar. 09-10, 2009 cen/isss ebif gtib project meeting,...

CEN/ISSS eBIF GTIB Project Meeting, BrusselsMar. 09-10, 2009

CEN/ISSS eBIF GTIB Project Meeting, Brussels 1

CEN/ISSS eBIF Global eBusiness Interoperability Test Bed Methodologies Project

Testing Requirements- Use Case 3 – eGovernment Public Procurement – UBL NES Profiles Tuncay Namlı and Prof. Dr. Asuman Dogac

SRDC Ltd.Ankara, Turkey



UBL & NES The Universal Business Language (UBL) initiative from OASIS

adopts the UN/CEFACT Core Component Technical Specification (CCTS) approach and develops a set of standard XML business document definitions Currently, the approved version of UBL is 2.0 and there are 31 XML schemas for

common business documents such as “Order”, “Despatch Advice” and “Invoice”. In addition to the document definitions, it provides a library of XML schemas

(XSDs) for reusable common data components like “Address”, “Item”, and “Payment” from which the documents are constructed.

The focus of Northern European Subset (NES) is to define the specific use of UBL 2.0 electronic procurement documents domestically and between the member countries (Denmark, Norway, UK, Sweden, Finland, Island)

CEN/BII overtook the development of NES Profiles



NES NES sets further restrictions on 8 UBL business

documents However, this schema refinement is performed with the

following restriction methodology: A refined schema can never extend a cardinality or data type A refined schema can always further restrict cardinality and data

type

The derived documents are called NES Generic Documents (e.g. NES Generic Invoice) and any document conformant with the NES generic schemas is also conformant with the UBL Schemas



NES Conformance The generic NES documents are further restricted for use in

particular business process context

These business process contexts are called NES Profiles which define the Actors, Business Processes and Rules on exchanged business documents

Conformance Criteria: UBL conformant NES conformant: A NES conformant instance is always UBL

conformant NES Profile conformant: A NES profile conformant instance is always

NES conformant and UBL conformant

CEN/ISSS eBIF GTIB Project Meeting, Brussels

Testing Requirements – NES Single Procurement Profile

Mar. 09-10, 2009 5CEN/ISSS eBIF GTIB Project

Meeting, Brussels


Testing Requirements – NES Single Procurement Profile NES Single Procurement Profile Scenarios:

Accepted Order, Accepted Invoice Rejected Order Accepted Order, Invoice Overcharge Accepted Order, Invoice Undercharge Accepted Order, Invoice contains wrong information

In order to claim that an application conforms to the NES Single Procurement Profile, the application should be successful in all of these scenarios

Therefore, we need at least one test case for each scenario for conformance testing of this profile

Mar. 09-10, 2009CEN/ISSS eBIF GTIB Project

Meeting, Brussels 6


Testing Requirements – NES Single Procurement Profile Req 1: The test framework should have the ability to present the

scenario flow to the SUT user in a descriptive way


Meeting, Brussels 7


Testing Requirements – NES Single Procurement Profile Req 2: The test framework should enable the users of the SUT to

monitor the test execution flow during the test execution In this way, they can also timely respond to the instructions that they

should perform


Meeting, Brussels 8


Testing Requirements – NES Single Procurement Profile Req 3: The test framework should enable test designers to setup

syntactic validation steps For NES Business documents, this validation step should do XML

validation according to the XML Schemas provided by UBL Note that:

NES and NES Profile validations are achieved through Schematrons Code Validations are realized through XSLT


Meeting, Brussels 9


Testing Requirements – NES Single Procurement Profile Req 4: The test framework should enable test designers

to setup validation steps which will check all coded elements in the business document

For NES and UBL, code validation is realized by using the XSLT file provided by the test designer

XSLT can be designed with the UBL Code List Value Validation Methodology according to the code lists specified by the NES

The output of the XSLT should be used as a test step report


Meeting, Brussels 11



7


Testing Requirements – NES Single Procurement Profile Req 5: The test framework should allow integration of different

validation components as plug-in so that test designers can select the most suitable validation methodology for specific test steps according to the auxiliary testing materials (e.g. XSLT files, UBL code list configuration files) they have



Code Lists in XSLT file

Code Lists inSchematron

File

Code Lists in GC file

Code List Server

TestFrameworkXSLT HandlerSchematron

HandlerA Specific Codelist

Handler

Validation Iterface


Testing Requirements – NES Single Procurement Profile Note that

NES defines refinements over UBL documents as business rules The Business rules are provided through Schematron rules

Req 6: The test framework should enable the test designer to setup a validation step which requires a Schematron as input and will do Schematron validation when executed

The output of the Schematron should be used as test step report



Single Procurement ProfileSome Invoice Document Restrictions


Testing Requirements – NES Single Procurement Profile Req 7: The test framework should enable test designers

to provide the scenario requirements (the information for business document contents) which will be presented to SUTs so that they can operate accordingly

Req 8: The test framework should enable test designers to setup test steps to realize value comparison for data elements

The expressions for these comparisons should bind the value of scenario requirements to some kind of representation in order to facilitate the test case maintenance




Testing Requirements – NES Single Procurement Profile Req 9: For business documents that will be sent to the SUTs, the

test framework should enable test designers to provide the document content at design time In accordance with the test scenario, this content can be real content that will be

directly used or a content template that will be updated during the test execution by further test steps

Req 10: The test framework should enable test designers to setup test steps to do special data processing and create new data. Inserting an XML fragment to a specified location in a document, setting the values of elements and attributes in an XML template or making some arithmetic calculations are examples for such processing instructions





Can be specified in design time.Should be generated at run time...-date: current day-UUID, ID: randomly generated numbers The values should be copied from the Order document that the SUT(Customer) sends at run time

The XML parts should be copied from the Order document that the SUT(Customer) sends at run time Depends on the test scenario, if the test case is

designed for the Rejected Order scenario:- specified at design time

If test case is generic; depends on some evaluation on the order document: - specified at run time


Testing Requirements – NES Single Procurement Profile In real life, before the test steps regarding the Invoice there is

actually one business step that should be performed (delivery of ordered items from supplier to customer)

In a test scenario, it is actually an imaginary delivery by informing the SUT that delivery is assumed to be completed

In addition some information about delivery should also be provided, since the overcharge situation in the NES Order Accepted, Invoice Overcharge scenario can be related with delivery

Req 11: The test framework should enable test designers to setup intermediate test steps which will interact with the SUT user over the graphical interface and provide some information about the running scenario




Testing Requirements – NES Single Procurement Profile Req 12: When a specific communication or transport protocol is not

specified in a profile or standard, the document exchanges should be realized over graphic interfaces. The test framework should enable test designers to setup test steps

which will interact with the SUT user and the test framework will get the business document over graphic interface uploaded by the SUT or provide a document created in the scenario for SUT to download.

Req 13: When a specific communication or transport protocol is specified, the test framework should enable test designers to setup test steps which have the capability to send or receive business

documents based on the selected protocol




Testing Requirements – Interoperability Scenario- Catalogue Only Profile and Single Procurement Profile Req 14: The test framework should also incorporate the automation

of the configuration management into the test case execution for both conformance and interoperability scenarios




Capturing and Testing the Exchanged Messages Req 15: In interoperability scenarios, there is a need to

capture and test the message exchanges among the SUTs

• For this purpose, a proxy mechanism is needed to act as a mediator which listens to the messages between the systems


An Example Scenario for Tests

Internet11011010

Testing Tool

WS SOAP

Interoperability TestCase for the

Examination Service

GITB Open Meeting, BrusselsJune 15, 2009

1101101011011010

Tests on message

Customer Supplier


Testing Requirements – Interoperability Scenario- Catalogue Only Profile and Single Procurement Profile Req 16: The test framework should enable test

designers to setup some branching (decision- if then else) test steps. The decision will be made by some conditional expression and the test case flow will continue with a branch according the result of the expression

Req 17: The test framework should enable test designers to setup some special test steps to repeat a set of test steps until a condition holds




Testing Requirements – Interoperability Scenario- Catalogue Only Profile and Single Procurement Profile





Thank you for your attention…

Questions?

cen/isss ebif gtib project meeting, brussels mar. 09-10, 2009 cen/isss ebif gtib project meeting,...

Documents

nes generic documents

nes conformant instance

nes generic invoice

nes generic schemas

ubl conformantnes conformant

ubl business documentshowever

common business documents

document conformant