1. CEN/ISSS eBIF GTIB Project Meeting, Brussels Mar. 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

2. CEN/ISSS eBIF GTIB Project Meeting, Brussels Mar. 09-10, 2009 CEN/ISSS eBIF GTIB Project Meeting, Brussels 2 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

3. CEN/ISSS eBIF GTIB Project Meeting, Brussels Mar. 09-10, 2009 CEN/ISSS eBIF GTIB Project Meeting, Brussels 3 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

4. CEN/ISSS eBIF GTIB Project Meeting, Brussels Mar. 09-10, 2009 CEN/ISSS eBIF GTIB Project Meeting, Brussels 4 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

5. CEN/ISSS eBIF GTIB Project Meeting, Brussels Testing Requirements – NES Single Procurement Profile Mar. 09-10, 2009 5 CEN/ISSS eBIF GTIB Project Meeting, Brussels

6. 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

7. 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

8. 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

9. 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

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

11. CEN/ISSS eBIF GTIB Project Meeting, Brussels 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

12. CEN/ISSS eBIF GTIB Project Meeting, Brussels Mar. 09-10, 2009 CEN/ISSS eBIF GTIB Project Meeting, Brussels 12 7

13. CEN/ISSS eBIF GTIB Project Meeting, Brussels 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 Mar. 09-10, 2009 CEN/ISSS eBIF GTIB Project Meeting, Brussels 13 Code Lists in XSLT file Code Lists inSchematron File Code Lists in GC file Code List Server TestFramework XSLT Handler Schematron Handler A Specific Codelist Handler Validation Iterface

14. CEN/ISSS eBIF GTIB Project Meeting, Brussels 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 Mar. 09-10, 2009 CEN/ISSS eBIF GTIB Project Meeting, Brussels 14 Single Procurement Profile Some Invoice Document Restrictions

15. CEN/ISSS eBIF GTIB Project Meeting, Brussels 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

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

17. CEN/ISSS eBIF GTIB Project Meeting, Brussels 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

18. CEN/ISSS eBIF GTIB Project Meeting, Brussels Mar. 09-10, 2009 CEN/ISSS eBIF GTIB Project Meeting, Brussels 18 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

19. CEN/ISSS eBIF GTIB Project Meeting, Brussels 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

20. CEN/ISSS eBIF GTIB Project Meeting, Brussels 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

21. CEN/ISSS eBIF GTIB Project Meeting, Brussels 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 Mar. 09-10, 2009 CEN/ISSS eBIF GTIB Project Meeting, Brussels 21

22. CEN/ISSS eBIF GTIB Project Meeting, Brussels 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

23. CEN/ISSS eBIF GTIB Project Meeting, Brussels 23 An Example Scenario for Tests Internet 11011010 Testing Tool WS SOAP Interoperability TestCase for the Examination Service GITB Open Meeting, Brussels June 15, 2009 11011010 Tests on message Customer Supplier

24. CEN/ISSS eBIF GTIB Project Meeting, Brussels 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 Mar. 09-10, 2009 CEN/ISSS eBIF GTIB Project Meeting, Brussels 24

25. CEN/ISSS eBIF GTIB Project Meeting, Brussels Testing Requirements – Interoperability Scenario- Catalogue Only Profile and Single Procurement Profile Mar. 09-10, 2009 CEN/ISSS eBIF GTIB Project Meeting, Brussels 25

26. CEN/ISSS eBIF GTIB Project Meeting, Brussels Mar. 09-10, 2009 CEN/ISSS eBIF GTIB Project Meeting, Brussels 26 Thank you for your attention… Questions?