prof. dr. asuman dogac, tuncay namli and fulya tuncer srdc ltd. [email protected] ankara, turkey

1

iSURF eDoCreator: e-Business Document Design And Customization EnvironmentandTestBATN: Testing Business, Application, Transport and Network Layers

Prof. Dr. Asuman Dogac, Tuncay Namli and Fulya TuncerSRDC [email protected], Turkey1

12th CEN/BII Meeting 15-18th June, OSLO

2

Outline Introduction to iSURF eDoCreator

Demo Introduction to TestBATN

Demo

CEN/ISSS Global Interoperability Test Bed (GITB) Project

How can our work be of use to CEN/BII and PEPPOL?


3

iSURF eDoCreator iSURF eDoCreator addresses the following

problems: Document artifacts are stored in spreadsheets

Hard to provide consistency among versions Not queryable No detailed and complete view of document building

blocks

Text-based UN/CEFACT CCTS modeling and UBL Customization guidelines

Hard to follow guidelines Error prone Time consuming


4

A Document Creation & Customization Process Creating, extending, customizing document schemas

conforming to UN/CEFACT CCTS methodology are tedious, labor intensive and time-consuming processes Analysis of available component interfaces Design of spreadsheet model of the document Creation of XSD files Creation of genericode files for each of the coded

attributes


5

Solution: iSURF eDoCreator iSURF eDoCreator tool addresses these problems by providing:

An online common graphical modeling environment which Converts paper-based UN/CEFACT CCTS based modeling and UBL customization guidelines into the machine processable

version Hence enables tracking of new models and

customizations

iSURF eDoCreator environment aims to maximize re use of available document building blocks and minimize the tedious document design and customization efforts as its aim is inline with UN/CEFACT CCTS

Used in the development of eInvoice Profile in Turkey


6

Overview of iSURF eDoCreator Online and 24/7 accessible graphical modeling

environment Web based Collaborative Modeling

Integrates and implements modeling approach of UN/CEFACT CCTS and UBL

– Modeling: UN/CEFACT CCTS– Customization: UBL

It is designed to aid the user in following these guidelines during the generation of standard-based and customized e-business documents


7

Architecture


8

Main Components User interface:

Abstracts the process steps via its Rich Internet Application

Guideline Processor: Main controller Converts paper-based guidelines into machine

processable format and guides the user Repository

Queryable, online and wiki-based repository


9

Repository Stores spreadsheet conceptual models in the machine processable

format

A common repository which is enriched by the contribution of users

Evolutionary: gradually enriched, as new document building blocks are customized or created

Collaborative: Authorized users can store new components and update its contents and anonymous users can only query the contents of the registry and retrieve the components

Currently, it contains: All of the BIEs in the common library of UBL 2.0 All the BIEs of the UN/CEFACT Cross Industry Electronic Invoice (CII) All the BIEs of NES and UBL-TR


10

Main Screen


12th CEN/BII Meeting 15-18th June, OSLO 11

Visualization Of Document Building Blocks

11

Conventional Model Document Designer

Document Model file

UBL Common Library file

Qualified Data Type fileUnqualified Data Type

•Presents document artifacts in a single Russian Doll modelas the tree expands

eDoCreator provides graphical modeling without dealing with spreadsheets or XSDs


12

Discovery Of Document Artifacts• Text based search: Increase sharing and reusability• Allow specification of keywords on

• Context values• Definition• Qualifiers• Dictionary entry names • Business Terms etc. based on document artifact type

• Logical connectors in query : “OR” vs “AND”• Search result includes both standard document artifacts provided by UBL

and standard-based document artifacts created by users• Get results within few seconds in contrast to searching in spreadsheets• Another feature “Filter by a keyword” to narrow down the list


13

Modeling Features Graphical modeling of standard-

based document artifacts: Based on UN/CEFACT CCTS

First discover, then create… Creation of components from

scratch by assembling available document building blocks

Message Assemblies Aggregate Business Information Entities Basic Business Information Entities

Creating of components based on available components Qualified Data Types

Customizing an existing one Qualifying a Unqualified Data Type


14

Modeling: Assembling Document Building Blocks

Assembling available document building blocks to a new document artifact in graphical model: (1) Drag

(2)Set properties of conceptual model

(3) Drop


15

Customization eDoCreator supports both

UBL Conformant Customization UBL Compatible Customization

“A UBL conformant instance is an instance validating against customized document constraints while simultaneously validating against a UBL standard schema.”

UBL Customization Guidelines v1.0 Tool watches the actions of the user and provides a

warning mechanism to alert the user that the resulting schema will be Compatible if the action is against conformant design rules and realized


16

Customization Subsetting original document artifacts

Removing document building blocks by un-checking nodes Automatic removal of inner document artifacts


17

Customization : 2 Subsetting through cardinality restriction

Changing cardinality Minimums can be increased to their maximum Maximums can be decreased to their minimum

Adding new document building blocks Through drag and drop feature


18

Customization: Schematron Placing constraints on the value space of information

entities and/or putting constraints among these values The Shipping Address must be the same as the Billing

Address The ProfileID must exits or be excluded. Title must have a value. Country attribute must be one of a value from ‘EN’,

“TR”, ‘IT’.. If CustomizationID exists then Customization

Organization must be exists. The cardinality of Address. Details must be greater or

equal to the cardinality of Person. Details


19

Exporting Documents• Export UBL Document schema

accompanied with some informative supporting materials in UBL directory format:– XML Schema of Document Assembly

with automatic translation from graphical model by UBL Naming and Design Rules

– Spreadsheet models defining the document assembly

– Genericode files for defining code lists (aka. enumerations or controlled vocabularies)


20

Importing Spreadsheets It support uploading of a new document model either from .ods

or .xls spreadsheet as new model generated. Validate according to UBL Spreadsheet Naming and Design

Rules eDoCreator provides validation and feedback mechanisms

Column Header Check, UBL Name Syntax Check, Existence check of Associated Aggregate Business Information Entity of Association Business Information Entity, Existence check of Data Type of Basic Business Information Entity, Dictionary Entry Name Check, Cardinality Check, Entity Check

Utilize other features of eDoCreator share it with the other users. Customize it Retrieve the documentation


21

Group Menu One of important issues is the privacy

Who can view my documents? Which documents am I allowed to view?

The owner or customizer of the document can select the groups or users to which the document model that he created is visible. You can only share the model with the groups that you are subscribed. To subscribe send a request to group owner from menu panel. You can also create a new group from menu panel

21

1

2

3

Select “PUBLIC” to make it available to all users


22

Gap Analysis Tool The Gap Analysis Tool compares two customized e-

business documents from document content perspective How you can provide interoperability? How interoperable your schemas ?

Four level of issues from minor problems to major problems Multiple Cardinality versus Optional Cardinality Optional Cardinality versus Excluded Element Optional Cardinality versus Mandatory Cardinality Mandatory Cardinality versus Excluded Element


23

Gap Analysis Report

2312th CEN/BII Meeting15-18th June, OSLO

24

eDoCreator Tool is publicly available at:

http://www.srdc.com.tr/index.php?option=com_content&task=view&id=229&Itemid=203


25

Overview of the tool :http://www.srdc.com.tr/eDoCreator/DocumentDesignerToolViewlets/main.htmCreating a new document artifact:http://www.srdc.com.tr/eDoCreator/DocumentDesignerToolViewlets/

createMessage.htmQualifying a data typehttp://www.srdc.com.tr/eDoCreator/DocumentDesignerToolViewlets/

datatype.htmConformant Customization:http://www.srdc.com.tr/eDoCreator/DocumentDesignerToolViewlets/

conformantCustomization.htmCompatible Customization:http://www.srdc.com.tr/eDoCreator/DocumentDesignerToolViewlets/

compatibleCustomization.htm


eDoCreator Demo Links

26

Demo Links• Retrieving documentation of Document Model:http://www.srdc.com.tr/eDoCreator/

DocumentDesignerToolViewlets/exportXSD.htm• Gap Analysishttp://www.srdc.com.tr/eDoCreator/

DocumentDesignerToolViewlets/iSurfeDoCreatorGapAnalysis.htm

• Uploading a document schema from a spreadsheethttp://www.srdc.com.tr/eDoCreator/

DocumentDesignerToolViewlets/importDocument.htmSetting group optionshttp://www.srdc.com.tr/eDoCreator/

DocumentDesignerToolViewlets/groupManagement.htm


27

iSURF EDoCreator Demo…

28June. 15, 2009 GITB Open Meeting, Brussels 28

Testing Requirements- Use Case 3 – eGovernment Public Procurement – UBLNES Profiles


UBL, NES, CEN/BII and PEPPOL 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 The large scale “Pan-European Public eProcurement On-Line

(PEPPOL)” Project will use CEN/BII Profiles


NES NES sets further restrictions on 8 UBL business

documents 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

32

NES Simple Procurement Profile

June. 15, 2009 32GITB Open Meeting, Brussels

33

Testing Requirements – NES Simple Procurement Profile NES Simple 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

June. 15, 2009 GITB Open Meeting, Brussels 33

34

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

scenario flow to the SUT user in a descriptive way


35

Testing Requirements – NES Simple 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, 2009CEN/ISSS eBIF GTIB Project

Meeting, Brussels 35June. 15, 2009 35GITB Open Meeting, Brussels

36

Testing Requirements – NES Simple 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



38

Testing Requirements – NES Simple 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



7

40

Testing Requirements – NES Simple 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

41

Testing Requirements – NES Simple 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


Simple Procurement ProfileExample Invoice Document Restrictions

42

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


44

Testing Requirements – NES Simple 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 or at run 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

46

Testing Requirements – NES Simple 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


47

Testing Requirements – NES Simple 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


48

Testing Requirements –Simple 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


49

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


505050

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


51

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


52

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



53

TestBATN Demo demonstrating UBLNES Simple Procurement Profile…

54

CEN/ISSS Global Interoperability Test Bed (GITB) Methodologies Project The major objective of this project is to develop the

first step for a set up of a comprehensive and global eBusiness interoperability test bed system http://www.ebusiness-testbed.eu/about-gitb/

The first deliverable is available for comment

55

How can these tools be of use to CEN/BII and PEPPOL? These tools are freely available on the Web

SRDC Team can provide support to further develop them for the specific needs of CEN/BII and PEPPOL

We hope collaborate with the PEPPOL Project…


Thank you for your attention…

Questions?

prof. dr. asuman dogac, tuncay namli and fulya tuncer srdc ltd. [email protected] ankara, turkey

Documents

cenbii meeting

new document

ubl modeling

paperbased uncefact

document artifacts

tedious document design

use of available document

ebusiness document design