e-CODEX DPS

Design of an e-CODEX Digital Procedural Standard - methodology, standards and definitions

Introduction

e-CODEX is based on open international standards and best practices. For each component of the e-CODEX framework the most appropriate standards were adopted, to ensure seamless integration of these components.

The standards and best practices currently on the e-CODEX service delivery, have been selected by guidance of European Commission’s ‘European Interoperability Framework’ (EIF) recommendations. The principles and recommendations of the EIF, where applicable, have been translated into the selected standards which have been documented in the architecture documentation that has been taken over from the former e-CODEX consortium and is annexed to the e-CODEX Regulation (point 5).

This document aims to make the Business Collaboration and Business Document XML schema designs more accessible for those who are not familiar with the approach of e-CODEX.

Quotes from the adopted standards are inserted in this document to clarify and/ or justify the described context of the Digital Procedural Standard design approach. For the reader that wants to explore the full standard definition, references to those standards are listed in the next section.

The importance of EIF

The European interoperability framework is a commonly agreed upon approach to the delivery of European public services in an interoperable manner. It provides basic interoperability guidelines in the form of common principles, models and recommendations.

The EIF distinguishes four levels of interoperability (legal, organisational, semantic, technical). In the context of e-CODEX the upper ‘legal interoperability’ layer is a given and is the starting point for any legal instrument digitalisation initiative as e-CODEX does not set standards or methodologies for that layer.

The ‘organisational’ layer is where the description of the business process provided in the Business Process Model fits. The Business Process Model deals with the behaviour of parties involved in executing their individual tasks in the context of a common cross-border collaboration.

The ‘semantic’ layer is where the definition of the Business Documents that are to be exchanged is provided in the form of XML schema definitions (XSDs). It covers the methodology of creating specifications for Business Documents using a common vocabulary.

The ‘technical’ layer specifies the functioning of the Gateway and Connector, the components that make e-CODEX cross-border communication possible.

The ebXML framework

e-CODEX has chosen the ebXML framework to obtain the organisational, semantic and technical interoperability, and more specifically these parts of the framework:

• the BPSS/ebBP standard to describe the behaviour between the organisational entities involved (the orchestration, using BPMN for visualising the interactions between organisations.
• the CCTS standard for semantic interoperability to specify Business Documents. The EU e-Justice Core Vocabulary was developed in the Consortium for the purpose of specification of Business Documents.

• the ebMS standard for technical interoperability. In addition to the ebMS standard, the ETSI REM evidence standard has been adopted as an alternative to the ebMS Business Signal specification. As this document is focused Business Collaboration design, ebMS and ETSI REM are not elaborated on.

   

Digital Procedural Standard (DPS)

The DPS, consisting of the Business Process Model document and the XML schema definitions, specifies both the organisational and the semantic interoperability layers for a specific legal instrument. The DPS is created based on input from the legal layer and representatives of the business entities involved in the organisational layer.

As stated above, the legal layer is the starting point for any digitalisation initiative of a legal instrument. Describing the DPS is not exclusively of value for legal and business representatives, but it provides valuable input for the configuration of the components in the infrastructural layer. Moreover, a DPS on collaboration behaviour and data structures in use, provides essential input for the design, adaptation or configuration of the connected Case Management Systems that are deployed behind the e-CODEX Gateway and Connector.

As the components in the various interoperability layers are ‘loosely coupled’, also the adopted standards are ‘loosely coupled’. However, by having selected standards that are of the same standards family, standards-based integration of these components is best achieved.

The ebBP/BPSS standard & terms

The commonly accepted modelling technique to document business processes is the ebBP standard as part of the BPSS technical specification. Business processes should be documented in a way that is understood both by the business actors and by the technical teams that support their business activities.

NOTE: [123-456] below references the line numbers in the ebBP standard documentation:

[213-231] ‘The eBusiness eXtensible Markup Language (ebXML) Business Process Specification Schema (BPSS) technical specification defines a standard language by which business systems MAY be configured to support the execution of Business Collaborations consisting of Business Transactions. […] The ebBP technical specification supports the specification of Business Transactions and the choreography of Business Transactions into Business Collaborations. All Business Transactions are implemented using one of many available standard patterns. These patterns are defined in the UMM specification. A pattern specifies the type of the message exchange (request, response and signals) that applies for a given Business Transaction definition.

The ebBP technical specification addresses Business Collaborations between any number of parties. It also enables participants, which are capable of using Web service or combined technology (such as ebXML and webservices) to participate in a Business Collaboration.’

[397-399] ‘As with all the other specifications in the ebXML framework, an ebBP process definition may be effectively used with other technologies. The ebXML has been composed of several independent, but related or aligned, components.’

[355-356] ‘The goal of ebBP technical specification is to provide the bridge between eBusiness process modelling and execution of eBusiness software components.’

As ebBP relates to the other specifications in the ebXML framework, an ebBP process definition supports the loose coupling and alignment needed to execute Business Collaborations. It provides the configuration parameters for the partners’ runtime systems in order to execute that Business Collaboration between a set of eBusiness software components [‘authorised e-CODEX access point’, art 3(3) & ‘Connected systems’, art 3(6) e-CODEX Regulation ].

Business Collaboration

[667-687] ‘A Business Collaboration (BC) is a set of business activities executing Business Transactions (BT) between business partners of collaborating partners. Each partner plays one or more abstract partners roles in the BC. […] BCs are expressed as a set of Business Activities between these roles. Each abstract partner role occupies a specific role when associated with a Business Activity.’

[436-450] ‘A Business Collaboration consists of a set of roles that collaborate by exchanging Business Documents (BD) through a set of choreographed transactions.’

An example of a Business Collaboration is shown below:

Business Transaction

[720-728] ‘A Business Transaction represents an atomic unit of work […] between two business partners. […] A Business Transaction is conducted between two parties playing opposite abstract roles in that transaction. Those roles are always generic and labelled as Requesting and Responding roles.’

[750-752] ‘A Business Transaction is a very specialized and very constraint protocol used to achieve very precise and enforceable transaction semantics and achieve state alignment when needed between both parties.’

[794-798] ‘A Business Transaction is realized as Business Document Flows between Requesting and Responding parties perform roles. There is always a logical requesting Business Document, and optionally a logical Responding Business Document., depending on the desired Business Transaction configuration: e.g. one-way notification […] or information vs. two-way conversation.’

Business Activity

[1131-1137] ‘A Business Action, an abstract element, is the holder of attributes that are common to both Requesting Business Activity and Responding Business Activity. […] Irrespective of whether or not a Response Business Document is required, a Responding Business Activity exists to support the mapping of the corresponding role and business action. Even when no Response Business Document is produced, there is a Responding Business Activity that occurs that receives and process the Request Business Document. Each activity has roles bound and linked to it.’

The above means, that for the design of a Business Transactions, regardless of the Message Exchange Pattern, at all times there is a Business Activity for both roles/entities engaged in the Business Transaction included. The Business Activity is ‘something that a collaborating partner does’ in order to instantiate the sending of a Business Document (message) or to process the received Business Document in the internal organisation (when no reply is expected) or to provide a reply (responding Business Document).

It should be possible to map the names of a Business Activity to an event in the internal workflow (description) of a collaborating partner.

The Business Activity name is conveyed to the set of configuration parameters for the infrastructure layer. The Business activity name is labelled ‘ebMS Action’ in that configuration file (pMode).

Choreography

[805-809] ‘The choreography of a Business Collaboration describes the ordering and transitions between Business Transaction or sub collaborations within a Business Collaboration. The choreography can be specified in the ebBP schema using diagram concepts such as: ‘start state’, ‘completion state’, ‘activities’, ‘forks’, ‘joins’, ‘decisions’, ‘transitions between activities’.’

The notation in BPMN helps to visually specify the choreography of a Business Collaboration. The (BPMN) notation used for e-CODEX Business Collaboration designs are explained in section Business Process modelling notation and intends to guide the reader of e-CODEX business collaboration designs in having a common understanding of the provided business collaboration models.

Business Document

A Business Document refers to all documents, reports, contracts, and records related to a particular business. Business Documents are essential instruments for decision-making, record-keeping and communication. They include a wide variety of written resources that support various corporate operations. Business Documents can be created on paper or electronically, depending on their audience and purpose, and can be used internally within the business or externally with the stakeholders of the community.

In e-CODEX context, Business Documents are always in electronic format and are often referred to as ‘messages’. However, a Business Document is not the same as ‘message’ in ebXML/ebMS terms and that distinction should be clear. A Business Document is part of an ebMS Message structure as ‘message payload’.

Tailored Business Documents for any type of interaction between collaborating partners are created based on the EU e-Justice Core Vocabulary. Each form associated with a legal instrument, and each additional communication required to successfully complete a Business Collaboration will be modelled into an XML Business Document.

The Business Documents are ‘machine readable’ as they are in XML, facilitating the automatic integration of the business information it holds into the business applications / case management systems of the collaborating entities. Typically, ‘human readable’ documents such as PDF or MS Word forms are attached to the Business Document. Additionally, any type of document (image, audio, video, etc.) can be attached.

Core Components

‘Core Components’ are semantic building blocks that can be used for all aspects of data and information modelling and exchange. Core components are the linchpin for creating interoperable business process models and business documents.’ (source: CCTS v3, section 5.1)

A core component is a semantic building block for creating clear and meaningful data models, vocabularies, and information exchange packages. Core components are used as the basis for creating business information entities. Examples of these reusable semantic building blocks are: ‘person’, ‘location’, ‘bank account’.

Ultimately the Core components and the derived business information entities are the basis for creating the Business Documents representing the forms associated with the EU legal instruments and additional message structures required for the Business Collaboration.

EU e-Justice Core Vocabulary

In e-CODEX, the asset deployed to (re)use semantical terms and definition and to ensure data consistency and data quality over time and across use case is the EU e-Justice Core Vocabulary. The Core Components (CCs) in use for the support to the digitalisation of the EU Justice domain are developed and maintained in this Core Vocabulary. Where the Core Components are specialised for the Justice domain they will be defined by the e-Justice community. Where the CCs are of more generic nature, they can be inherited from ‘higher vocabularies’ as defined by EU EuroVoc, United Nations, ISO or other entities. Examples of these inherited CCs are ‘person’ and ‘location’.

By applying the CCTS standard, established Core Components can be tailored for use in the digital support to specific European legal instruments. The methodology of deriving business information entities and creating XML schema Business Documents fulfils the exact information requirement articulation as laid down in forms associated with the legal instrument, message structures as established in implementing act or by sub-groups of the e-CODEX Advisory Group.

In addition, the EU e-Justice Core Vocabulary stores reusable (standardised) code lists, allowing for consistent use of code lists across legal instrument use-cases. The use of a common vocabulary ensures consistency and sustainability of terms and definitions used in the e-Justice domain. It facilitates ease of implementation by the participants in the e-Justice community, minimizing the impact of EU collaborations on the respective domestic judicial systems.

The deployment of a Core Vocabulary and the way it is maintained is in line with Commission’s EIF recommendation 31.

Learn More

Back to e-CODEX