iSURF eDoCreator: eBusiness Document Design And Customization Environment and TestBATN: Testing Busi

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
  Tuncer
• SRDC Ltd.
• asuman_at_srdc.com.tr
• Ankara, Turkey

1
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?

2
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

3
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

4
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

5
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

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

8
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

9
10
Main Screen
10
11
Visualization Of Document Building Blocks

• Document Designer

• Conventional Model

Document Model file
UBL Common Library file
Qualified Data Type file

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

Unqualified Data Type
eDoCreator provides graphical modeling without
dealing with spreadsheets or XSDs
11
12th CEN/BII Meeting 15-18th June, OSLO
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

12
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

13
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

14
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

15
16
Customization

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

16
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

17
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

18
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)

19
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

20
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

1
Select PUBLIC to make it available to all users
2
3
21
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

22
23
Gap Analysis Report
23
24
eDoCreator

• Tool is publicly available at
• http//www.srdc.com.tr/index.php?optioncom_conten
  ttaskviewid229Itemid203

24
25
eDoCreator Demo Links

• Overview of the tool
• http//www.srdc.com.tr/eDoCreator/DocumentDesigner
  ToolViewlets/main.htm
• Creating a new document artifact
• http//www.srdc.com.tr/eDoCreator/DocumentDesigner
  ToolViewlets/createMessage.htm
• Qualifying a data type
• http//www.srdc.com.tr/eDoCreator/DocumentDesigner
  ToolViewlets/datatype.htm
• Conformant Customization
• http//www.srdc.com.tr/eDoCreator/DocumentDesigner
  ToolViewlets/conformantCustomization.htm
• Compatible Customization
• http//www.srdc.com.tr/eDoCreator/DocumentDesigner
  ToolViewlets/compatibleCustomization.htm

25
26
Demo Links

• Retrieving documentation of Document Model
• http//www.srdc.com.tr/eDoCreator/DocumentDesigner
  ToolViewlets/exportXSD.htm
• Gap Analysis
• http//www.srdc.com.tr/eDoCreator/DocumentDesigner
  ToolViewlets/iSurfeDoCreatorGapAnalysis.htm
• Uploading a document schema from a spreadsheet
• http//www.srdc.com.tr/eDoCreator/DocumentDesigner
  ToolViewlets/importDocument.htm
• Setting group options
• http//www.srdc.com.tr/eDoCreator/DocumentDesigner
  ToolViewlets/groupManagement.htm

26
27

• iSURF EDoCreator Demo

28
Testing Requirements- Use Case 3 eGovernment
Public Procurement UBLNES Profiles
June. 15, 2009
28
GITB Open Meeting, Brussels
29
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

June. 15, 2009
29
GITB Open Meeting, Brussels
30
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

June. 15, 2009
30
GITB Open Meeting, Brussels
31
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

June. 15, 2009
31
GITB Open Meeting, Brussels
32
NES Simple Procurement Profile
June. 15, 2009
32
GITB 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
33
GITB Open Meeting, Brussels
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

June. 15, 2009
34
GITB Open Meeting, Brussels
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, 2009
35
June. 15, 2009
35
CEN/ISSS eBIF GTIB Project Meeting, Brussels
GITB 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

Mar. 09-10, 2009
36
June. 15, 2009
36
CEN/ISSS eBIF GTIB Project Meeting, Brussels
GITB Open Meeting, Brussels
37
June. 15, 2009
37
GITB Open Meeting, Brussels
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

June. 15, 2009
38
GITB Open Meeting, Brussels
39
7
June. 15, 2009
39
GITB Open Meeting, Brussels
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

Validation Iterface
June. 15, 2009
40
GITB Open Meeting, Brussels
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 Profile Example Invoice
Document Restrictions
June. 15, 2009
41
GITB Open Meeting, Brussels
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

June. 15, 2009
42
GITB Open Meeting, Brussels
43
June. 15, 2009
43
GITB Open Meeting, Brussels
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

June. 15, 2009
44
GITB Open Meeting, Brussels
45
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
June. 15, 2009
45
GITB Open Meeting, Brussels
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

June. 15, 2009
46
GITB Open Meeting, Brussels
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

June. 15, 2009
47
GITB Open Meeting, Brussels
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

June. 15, 2009
48
GITB Open Meeting, Brussels
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

June. 15, 2009
49
GITB Open Meeting, Brussels
50
An Example Scenario for Tests
Internet
11011010
11011010
11011010
Customer
Supplier
Tests on message
Interoperability TestCase for the Examination
Service
Testing Tool
50
50
June 15, 2009
June. 15, 2009
50
GITB Open Meeting, Brussels
GITB Open Meeting, Brussels
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

June. 15, 2009
51
GITB Open Meeting, Brussels
52
Testing Requirements Interoperability Scenario-
Catalogue Only Profile and Simple Procurement
Profile
Mar. 09-10, 2009
52
June. 15, 2009
52
CEN/ISSS eBIF GTIB Project Meeting, Brussels
GITB Open Meeting, Brussels
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

56
Thank you for your attentionQuestions?
June. 15, 2009
GITB Open Meeting, Brussels
56