Tuncay Namlı and Prof. Dr. Asuman Dogac SRDC Ltd. Ankara, Turkey

1. CEN/ISSS eBIF Global eBusiness Interoperability Test Bed Methodologies ProjectTesting Requirements- Use Case 3 – eGovernment Public Procurement – UBL NES Profiles Tuncay Namlı and Prof. Dr. Asuman Dogac SRDC Ltd. Ankara, Turkey CEN/ISSS eBIF GTIB Project Meeting, Brussels CEN/ISSS eBIF GTIB Project Meeting, Brussels

2. UBL & NES CEN/ISSS eBIF GTIB Project Meeting, Brussels CEN/ISSS eBIF GTIB Project Meeting, Brussels • 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. NES CEN/ISSS eBIF GTIB Project Meeting, Brussels CEN/ISSS eBIF GTIB Project Meeting, Brussels • 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. NES Conformance CEN/ISSS eBIF GTIB Project Meeting, Brussels CEN/ISSS eBIF GTIB Project Meeting, Brussels • 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. Testing Requirements – NES Single Procurement Profile CEN/ISSS eBIF GTIB Project Meeting, Brussels 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 CEN/ISSS eBIF GTIB Project Meeting, Brussels CEN/ISSS eBIF GTIB Project Meeting, Brussels

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

8. Testing Requirements – NES Single Procurement Profile • Req2: 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 8 CEN/ISSS eBIF GTIB Project Meeting, Brussels CEN/ISSS eBIF GTIB Project Meeting, Brussels

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

10. CEN/ISSS eBIF GTIB Project Meeting, Brussels CEN/ISSS eBIF GTIB Project Meeting, Brussels

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

12. 7 CEN/ISSS eBIF GTIB Project Meeting, Brussels CEN/ISSS eBIF GTIB Project Meeting, Brussels

13. Testing Requirements – NES Single Procurement Profile • Req5: 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 XSLT Handler A Specific Codelist Handler TestFramework Code Lists inSchematron File Schematron Handler Code List Server CEN/ISSS eBIF GTIB Project Meeting, Brussels CEN/ISSS eBIF GTIB Project Meeting, Brussels

14. 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 • Req6: 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 CEN/ISSS eBIF GTIB Project Meeting, Brussels CEN/ISSS eBIF GTIB Project Meeting, Brussels

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

16. CEN/ISSS eBIF GTIB Project Meeting, Brussels CEN/ISSS eBIF GTIB Project Meeting, Brussels

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

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

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

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

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

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

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

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

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

26. Thank you for your attention…Questions? CEN/ISSS eBIF GTIB Project Meeting, Brussels CEN/ISSS eBIF GTIB Project Meeting, Brussels