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
Mar. 09-10, 2009
CEN/ISSS eBIF GTIB Project Meeting,
Brussels
1
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
Mar. 09-10, 2009
CEN/ISSS eBIF GTIB Project Meeting,
Brussels
2
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
Mar. 09-10, 2009
CEN/ISSS eBIF GTIB Project Meeting,
Brussels
3
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
Mar. 09-10, 2009
CEN/ISSS eBIF GTIB Project Meeting,
Brussels
4
Testing Requirements – NES Single
Procurement Profile
Mar. 09-10, 2009
CEN/ISSS eBIF GTIB Project Meeting,
Brussels
5
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, 2009
CEN/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
Mar. 09-10, 2009
CEN/ISSS eBIF GTIB Project 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
Mar. 09-10, 2009
CEN/ISSS eBIF GTIB Project 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
Mar. 09-10, 2009
CEN/ISSS eBIF GTIB Project Meeting,
Brussels
9
Mar. 09-10, 2009
CEN/ISSS eBIF GTIB Project Meeting,
Brussels
10
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
Mar. 09-10, 2009
CEN/ISSS eBIF GTIB Project Meeting,
Brussels
11
7
Mar. 09-10, 2009
CEN/ISSS eBIF GTIB Project Meeting,
Brussels
12
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
Validation
Iterface
Code Lists in
XSLT file
Code Lists in
GC file
Schematron
A Specific
Codelist
XSLT
Handler
Handler
Handler
Code Lists
inSchematron
File
Mar. 09-10, 2009
TestFramework
Code List Server
CEN/ISSS eBIF GTIB Project Meeting,
Brussels
13
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 Profile
Some Invoice Document Restrictions
Mar. 09-10, 2009
CEN/ISSS eBIF GTIB Project Meeting,
Brussels
14
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
Mar. 09-10, 2009
CEN/ISSS eBIF GTIB Project Meeting,
Brussels
15
Mar. 09-10, 2009
CEN/ISSS eBIF GTIB Project Meeting,
Brussels
16
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
Mar. 09-10, 2009
CEN/ISSS eBIF GTIB Project Meeting,
Brussels
17
The XML parts should be copied from the Order
document that the SUT(Customer) sends at run
Depends
on the test scenario, if the test case is
time
designed for the Rejected Order scenario:
- specified
at design
Should
be
generated
attime
run
Can
be specified
in time...
design time.
If
test
case
is
generic;
depends
on some
-date:
current
day be copied from
The
values
should
evaluation on the order document: the Order
-UUID,
ID: that
randomly
generated numbers
document
the
SUT(Customer)
sends at run
- specified
at
run
time
time
Mar. 09-10, 2009
CEN/ISSS eBIF GTIB Project Meeting,
Brussels
18
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
Mar. 09-10, 2009
CEN/ISSS eBIF GTIB Project Meeting,
Brussels
19
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
Mar. 09-10, 2009
CEN/ISSS eBIF GTIB Project Meeting,
Brussels
20
Testing Requirements – Interoperability ScenarioCatalogue 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
Mar. 09-10, 2009
CEN/ISSS eBIF GTIB Project Meeting,
Brussels
21
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

CEN/ISSS eBIF GTIB Project Meeting,
Brussels
An Example Scenario for Tests
WS SOAP
Internet
11011010
11011010
Customer
Tests on
message
Interoperability
TestCase for the
Examination Service
June 15, 2009
Supplier
Testing
Tool
CEN/ISSS eBIF GTIB Project Meeting,
GITB OpenBrussels
Meeting, Brussels
23
Testing Requirements – Interoperability ScenarioCatalogue 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
Mar. 09-10, 2009
CEN/ISSS eBIF GTIB Project Meeting,
Brussels
24
Testing Requirements – Interoperability ScenarioCatalogue Only Profile and Single Procurement
Profile
Mar. 09-10, 2009
CEN/ISSS eBIF GTIB Project Meeting,
Brussels
25
Thank you for your attention…
Questions?
Mar. 09-10, 2009
CEN/ISSS eBIF GTIB Project Meeting,
Brussels
26