e-PRIOR Software Architecture Document · PDF fileSoftware Architecture Document Date:...

Commission européenne, B-1049 Bruxelles / Europese Commissie, B-1049 Brussel - Belgium. Telephone: (32-2) 299 11 11. Commission européenne, L-2920 Luxembourg. Telephone: (352) 43 01-1.

EUROPEAN COMMISSION DIRECTORATE-GENERAL INFORMATICS Information systems Directorate

European Commission

Central Catalogue Management System Software Architecture Document

Date: 07/10/2010

Version: 1.1

Authors: Fausto Rubino, Marco Fichera

Revised by: Sandro D'Orazio, Didier Thunus

Approved by:

Public:

Reference Number:

Central Catalogue Management System Software Architecture Document Page i

TABLE OF CONTENTS

1. INTRODUCTION .................................................................................................................................... 3

1.1. Purpose .................................................................................................................................................... 3 1.2. Scope ....................................................................................................................................................... 3 1.3. References ............................................................................................................................................... 3 1.4. General Overview.................................................................................................................................... 3 1.5. Document Content Overview .................................................................................................................. 5

2. USE-CASE VIEW .................................................................................................................................... 5

2.1. Use Cases Selection................................................................................................................................. 5 2.2. Architecturally significant Use Cases Diagram....................................................................................... 6

3. LOGICAL VIEW ..................................................................................................................................... 7

3.1. Overview ................................................................................................................................................. 7 3.2. Architecturally Significant Design Packages .......................................................................................... 7 3.3. Security.................................................................................................................................................... 9

4. IMPLEMENTATION VIEW................................................................................................................ 12

4.1. Use-Case Realizations ........................................................................................................................... 12 4.1.1. The Catalogue Provider submits a Catalogue..................................................................................... 13 4.1.2. The End-User consults the information concerning the Catalogue .................................................... 17 4.1.3. The End-User validates the information concerning the Catalogue ................................................... 20

5. DATA VIEW........................................................................................................................................... 25

Central Catalogue Management System Software Architecture Document Page ii

Document History

Version Date Comment Modified Pages

0.01 01/10/2010 First Version All

0.02 05/10/2010 Added references and revised by Sandro D'Orazio As required

1.0 07/10/2010 Revised by Tanya Chetcuti As required

1.1 01/12/2010 Added Validate Catalogue Use Case implementation

Modified architecturally relevant use cases and packages diagram.

Modified architecturally relevant use cases diagram.

Added chapter describing the security layer

Added chapter describing the data model layer

4.1.3 Validate use case

Figure 6: Package diagram

Figure 1: Use Cases Diagram

3.3 Security

5. Data View

Central Catalogue Management System Software Architecture Document – Page 3 / 27 Document Version 1.0 dated 14/12/2010

1. INTRODUCTION

1.1. Purpose

This document provides a comprehensive architectural overview of the system, using a number of different architectural views to depict different aspects of the system. It is intended to capture and convey the significant architectural decisions which have been made on the system.

1.2. Scope

The architecture described in this document concerns the Central Catalogue Management System.

1.3. References

# Document Contents outline

[REF1] Spring Framework http://www.springsource.org/

[REF2] Data Access Object http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html

[REF3] EJB 3.0 / JPA http://jcp.org/aboutJava/communityprocess/final/jsr220/

[REF4] Hibernate http://www.hibernate.org/

[REF5] UBL 2.0 http://docs.oasis-open.org/ubl/cs-UBL-2.0/UBL-2.0.html

[REF6] XMLBeans http://xmlbeans.apache.org/

[REF7] Spring Transaction Management

http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/transaction.html

[REF8] DOJO http://www.dojotoolkit.org/

[REF9] Javascript https://developer.mozilla.org/en/JavaScript

[REF10] Spring MVC http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/mvc.html

[REF11] JAAS http://download.oracle.com/javase/1.4.2/docs/guide/security/jaas/tutorials/GeneralAcnOnly.html

[REF12] Open e-PRIOR software architecture document

http://forge.osor.eu/docman/view.php/188/424/Open%20e-PRIOR%20SAD%202.0.pdf

[REF13] Mapping between CCMS data model and UBL entities

TO BE COMPLETED

1.4. General Overview

The Central Catalogue Management System (CCMS) is an application that provides several services for storing, handling, querying and consulting electronic Catalogues.

The CCMS provides services both to end-users, who can access the application via a web interface and to external systems, such as e-PRIOR, which want access e-Catalogues information. Access is provided using standard interoperable interfaces such as web-services and JMS queues.

CCMS is designed to manage UBL 2.0 e-Catalogues, and all data formats (services contracts, XML documents) comply with this standard.

http://www.springsource.org/

http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html

http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html

http://jcp.org/aboutJava/communityprocess/final/jsr220/

http://www.hibernate.org/

http://docs.oasis-open.org/ubl/cs-UBL-2.0/UBL-2.0.html

http://docs.oasis-open.org/ubl/cs-UBL-2.0/UBL-2.0.html

http://xmlbeans.apache.org/



http://www.dojotoolkit.org/

https://developer.mozilla.org/en/JavaScript

http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/mvc.html

http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/mvc.html

http://download.oracle.com/javase/1.4.2/docs/guide/security/jaas/tutorials/GeneralAcnOnly.html

http://download.oracle.com/javase/1.4.2/docs/guide/security/jaas/tutorials/GeneralAcnOnly.html

http://forge.osor.eu/docman/view.php/188/424/Open e-PRIOR SAD 2.0.pdf

http://forge.osor.eu/docman/view.php/188/424/Open e-PRIOR SAD 2.0.pdf


The CCMS includes an internal database to store e-Catalogues data, which reflects UBL 2.0 data structure.

The following table shows the services provided to end-users and external applications by the CCMS:

Service External Application Human End-Users

Import Catalogue X

View Catalogue X

Validate Catalogue X


1.5. Document Content Overview

This document details the architecture of the CCMS using several architectural views:

• Use Case view: architecturally significant use cases are shown via a use case diagram

• Logical view: the main layers and components are explained, with the aid of a package diagram

• Implementation view: This view gives implantation details on the selected use cases. Low-level package diagrams, class diagrams and sequence diagrams are used at this stage.

2. USE-CASE VIEW

This section provides a representation of the architecturally significant Use Cases.

2.1. Use Cases Selection

The architecturally significant Use Cases have been selected based on the following criteria:

• Use Cases affecting multiple components of the system, thereby providing a cross-cutting view of the system architecture.

• Use Cases representing critical parts of the architecture, thereby addressing the technical risks of the project at an earlier stage.

The following Use Cases have been selected.

• Use Cases addressing the submission of documents by external applications (Submit Catalogue use case)

• Use Cases involving end users accessing e-Catalogue information via the web interface (Validate Catalogue Use Case, View Catalogue Use Case)


2.2. Architecturally significant Use Cases Diagram

Figure 1: Use Cases Diagram


3. LOGICAL VIEW

3.1. Overview

This chapter describes the main application packages, how they interact and how they implement system Use Cases.

In subsection 3.2 we describe the main packages of the system, how they are called by the system users and how they interact with each other.

3.2. Architecturally Significant Design Packages

The following diagram provides a high level view of the main packages composing the system. This diagram shows also the system users (represented as UML actors).

Figure 2: System Users and Main Packages

• Catalogue Provider Integration System: the Catalogue provider, in order to submit Catalogues to the system, uses an external integration system which is capable of sending UBL 2.0 documents to the CCMS using a standard JMS interface.

• Presentation Layer: responsible for the presentation of the data to the end-user via a web user interface. When the users want to have access to the catalogue data, they can log in the web application provided by the CCMS and submit a request to the system specifying the needed search parameters. The presentation layer is in charge of transforming the user request into a representation compliant with the business layer interfaces, sending the data to the business layer and showing the response to the end user through a human readable format. The web pages of the application use DOJO [REF8] JavaScript [REF9] libraries and requests are handled using the Spring MVC (Model, View, Controller) framework [REF10].

• Integration Layer: the CCMS integration layer is responsible of receiving, transforming and submitting to the business layer the requests coming from external applications. For example, for the Import Catalogue Use Case, the integration layer reads the message containing the Catalogue from a JMS queue checks the validity of the message and calls the business layer for document processing.


• Business Layer: the business layer is the core layer of the application which performs all the business activities related to requests coming from human users or external applications. It is in charge of:

o Transforming the incoming requests into an internal business model;

o Processing the different elements of the catalogue and handling their persistence in the database by calling the data access layer;

o Processing incoming requests for information retrieval and handling the related database calls by calling the data access layer;

o Handling the database transactions for preserving data integrity.

The business layer can be split in the following tiers:

o Façade: this tier provides the interfaces towards external systems. The classes belonging to this tier provide simple interfaces which hide all the complex interactions amongst business components. The façades are responsible for orchestrating the interactions between classes belonging to the underlying tier.

o Service: this tier centralizes the transaction control in a coarse-grained way and interacts with the classes belonging to the handler tier. The transaction management is completely delegated to the Spring Framework [REF1] which provides a consistent programming model to deal with transactions.

o Handler: this tier contains the implementation of the business logic and exposes atomic and fine-grained interfaces. Moreover, the handler tier is responsible for interacting with the data access layer in order to execute atomic operations on the central catalogue repository.

• Data Access Layer: This layer has the responsibility for providing the interfaces access to data stored in the database repository. The Data Access Layer is composed of the following two main components:

o Data Access Object (DAO) [REF2]: The DAO implements the logic required to access and to perform atomic operations on the central catalogue repository. The business classes use the interface exposed by the DAO so that the implementation details are completely hidden. CCMS provides a DAO implementation based on the JPA [REF3] specification and Hibernate [REF4] implementation;

o Entity [REF3]: The Entity objects are Java Classes mapping the database structure. The state of the Entity objects can be persisted in the database.

• Logging Layer: the Logging layer is used across all the other layers to log all the technical operations performed by the application.

• Security Layer: the Security layer provides to the interface layers (Integration and Presentation) the means to check authentication and authorization of the human end-user or of the external application.


3.3. Security

The presentation layer uses the security layer to check authentication and authorization of the user who wants to access to the system. The following diagram shows a detailed view of the security layer.

Figure 3: Security layer packages

As the Figure 3: Security layer packages" shows, the security layer includes both authentication and authorization processes.

The authentication mechanism is delegated to the application server which must be configured in order to allow the user authentication. By creating this abstraction layer, CCMS can use a common interface to different authentication mechanism such as LDAP, CAS, X.509, etc. For more information about JAAS please refer to [REF11].

The authorization mechanism is completely decoupled from authentication and it is managed directly by CCMS.

CCMS bases the authorization decisions on:

• Authenticated user<U> to be authorized;

• Task<T> to be carried out;

• Domain object<O> (catalogue instance).


The authorization mechanism checks if the user U is authorized to perform the task T on the domain object O.

In order to understand how the authorization logic is implemented, we need to introduce the concept of Framework Contract <FC>. A framework contract is definition to be completed. Each catalogue must belong to one framework contract.

The end-user can play different roles on different framework contracts. If the user <U> has the role <R> on the framework contract <FC>, it means that U has all the permissions linked to the role R on the catalogues belonging to the framework contract FC.

In details, for each framework contract an end-User may act as a Catalogue Validator or as a Catalogue Reviewer. The table below provides further information about the permissions of these roles.

Figure 4: end-User Roles


Validate Catalogue View Catalogue

Create Note Approve Reject Confirm Approval

Validator Catalogues, in all states, that belong to a contract for

which the User is "Validator"

Yes Yes Yes No

Use

r rol

es

Reviewer Catalogues, in all states, that belong to a contract for

which the User is "Reviewer"

Yes No No Yes

Figure 5: Permissions


4. IMPLEMENTATION VIEW

4.1. Use-Case Realizations

The following architecturally relevant Use Cases have been chosen, to describe how software components behave:

• A Catalogue provider submits a Catalogue using its integration system;

• A Customer views the information of a catalogue;

• A Customer validates the information of a catalogue.

The implementation of these three Use Cases involves all of the components and all the layers of the architecture. The description of the realization of these Use Cases will then be sufficient to explain how all the components of the CCMS architecture interact with each other.

The following sections provides :

• High-level class diagrams which explain the relationship between the classes of different layers of the architecture.

• High-level sequence diagrams to emphasize interactions between components and layers.


4.1.1. The Catalogue Provider submits a Catalogue A catalogue provider can submit a catalogue via its integration system capable of sending UBL 2.0 [REF5] documents to the CCMS using a standard JMS interface. The import process starts when a new JMS message is enqueued in the CCMS queue.

The two following diagrams provide a more detailed view of the different layers composing the system.

Figure 6: Package diagram


Figure 7: Class diagram

The import of a Catalogue, due to the complexity of the XML document itself and of the underlying database table, takes advantage of the different layers of the architecture, grouping together fine-grained operations which involve the different objects that compose the Catalogue.

In detail, the following tasks are performed during the import of a Catalogue:

• Saving into the database the data about the catalogue header information: catalogue id, catalogue version, parties' involved, referenced contract. This is the first step, since the subsequent catalogue lines will be associated with the newly created catalogue;

• Saving the catalogue lines one by one into separate transactions. At this stage, the lines contained in the catalogue are stored into the database. Transactions are separated, since correct catalogue lines have to be imported even if errors are raised by other lines;

• Updating the version information concerning the items. A comparison is done with the previous version of the Catalogue (if it exists): deleted and updated lines are removed, new items and the unchanged items are associated with the new version of the catalogue;

• Creating the relationships among the items;

• Associating the available language translations to the catalogue version. Textual descriptions inside the catalogue can indeed be stored in different languages, which can then be chosen by the user when viewing the catalogue;

• Processing report. A report is created about the processing of the import of the catalogue, in which errors or alerts on single Catalogue lines are logged.

The following sequence diagram describes the main possible interactions amongst the components described above.


Figure 8 Sequence Diagram

4.1.1.1. Submit Catalogue in the Integration Layer When a Supplier submits a Catalogue to the CCMS system via the JMS queue, the integration layer reads the message using a Message Driven Bean, which validates it against the Catalogue UBL 2.0 XSD and transforms it into objects compliant with the interfaces exposed by the business layer (Data Transfer Objects - DTO). Messages are validated using the XMLBeans [REF6] validation features and transformed into DTO using a Message Transformer which is a Java Class aware of the objects representation.

4.1.1.2. Submit Catalogue in the Business Layer The Catalogue Facade class exposes a coarse-grained interface to import the catalogue.

The method submitCatalogue() starts the business logic for importing the catalogue. The import is split into different transactions which can be summarized as follow:

• Catalogue level transaction: in this transaction the catalogue entity is created and versioned. Moreover all of the information directly connected to the catalogue such as parties and


framework contract associations are created in this transaction. The transaction is managed by Spring [REF7] when the method saveAndVersionCatalogue() of the ImportCatalogueService class is called;

• Catalogue Line transactions: for each catalogue line a separate transaction is executed. In detail, for each line one of the following action code is specified:

o ADD, for adding a catalogue line to the specified catalogue;

o DELETE, for removing a catalogue line from the specified catalogue;

o UPDATE, for updating a catalogue line from the specified catalogue;

The transactions are managed by spring when the method saveAndVersionCatalogueLine() of the ImportCatalogueService class is called.

When the transactions are executed the ImportCatalogueService coordinates the calls to methods of specialized handlers which contain fine-grained logic. For the Import of the catalogue we have different handlers playing different roles:

• CatalogueHandler: contains the business logic to create or update the catalogue entity;

• VersioningHandler: contains the business logic to version the catalogue and its catalogue lines;

• PartyHandler: contains the business logic to save and update the parties and link them to the catalogues/catalogue lines;

• ItemHandler: contains the business logic to save and update the catalogue lines.

The handlers interact with the classes responsible for performing the atomic operations on the database. These classes belong to the underlying layer called Data Access Layer described below.

4.1.1.3. Submit Catalogue in the Data Access Layer As described in 3.2, the Data Access Layer is composed of the following two main components:

• Data Access Object (DAO) [REF2]

• Entity [REF3]

An entity is a lightweight persistent domain object. Each entity represents a table in a relational database, and each entity instance corresponds to a row in that table.

In addition to the entities, each table has a DAO class linked to it. Each of these DAO classes extends a generic DAO class called JpaDAO. The JpaDAO implements the DAO interface using Jpa and spring technology. The DAO exposes the following methods for performing atomic operations on the database:

• persist(): persists the entity

• delete(): deletes an existing entity

• findByPk(): finds an entity based on the primary key passed as parameter

• findAll(): finds all the entities stored in the database


4.1.2. The End-User consults the information concerning the Catalogue Once the user rights have been verified, the web application provides the following features:

• Search Catalogue: the user can retrieve catalogues specifying the following search parameters:

o Catalogue ID

o Catalogue Version

o Framework Contract (one of the framework contract for which the user is either validator of reviewer)

o Lifecycle status

The user can consult only the catalogues belonging to a framework contract for which it is either validator of reviewer.

• View Catalogue: once the user identifies the catalogue, the following details are provided:

o Customer header information

o Supplier header information

o Catalogue line classification information

o Catalogue line details information

Below are some sample screens referring to the information described above:

Figure 9: Search Catalogue Screen


Figure 10: Catalogue Details Screen

Figure 11: Item Details Screen


4.1.2.1. View Catalogue in the Presentation Layer The presentation layer handles the user's search requests and shows the required Catalogue information.

Authentication is required for the user, who has to provide a username and a password before using the CCMS functionalities. Credentials are checked using the services provided by the Security Layer of the architecture.

The Controllers validates the request coming from the View and transforms it into a format ready to be passed to the underlying Business Layer. The transformed request is then submitted to the Façade tier of the Business Layer and, when the response is received, data is transformed back into a format ready to be shown by the View.

Three main controller classes are used by the application to handle the requests for the view catalogue use case:

• SearchCatalogueController: this controller is used when the user search for a catalogue providing the search parameters via the web interface;

• ViewCatalogueController: this controller is in charge of getting the Catalogue Details by calling the services of the Business Layer, when the user selects a Catalogue to consult from the list of the available ones;

• CatalogueItemDetailsController: this controller is called when a user selects an item from the catalogue lines list of a specified Catalogue.

4.1.2.2. View Catalogue in the Business Layer The CatalogueFacade class exposes an interface for both searching catalogues (based on search parameters) and fetching the details of a specific catalogue (based on its primary key). The CatalogueFacade class exposes the following tree methods:

• findCatalogues(): orchestrates the calls to the service tier in order to find the catalogue information according to the provided parameters;

• getCatalogueSynopsis(): orchestrates the calls to the service tier in order to find the catalogue synopsis information. The catalogue synopsis contains all the catalogue information except for the information concerning the catalogue lines;

• getItemDetails(): orchestrates the calls to the service tier in order to find the catalogue line information.

The CatalogueQueryService coordinates the calls to the methods of the handlers containing a more fine-grained logic used to fetch the information linked to the catalogues and catalogue lines. The CatalogueQueryService interatcs with the following handlers:

• CatalogueQueryHandler: contains the business logic to fetch the information concerning the catalogue entities;

• ItemQueryHandler: contains the business logic for fetching the information concerning the catalogue lines entities.

The handlers interact with the classes responsible for executing atomic queries on the database. These classes belong to the Data Access Layer described in 4.1.1.3.


4.1.3. The End-User validates the information concerning the Catalogue Once the user identifies and consults the catalogue, the system provides a multi step approval workflow which enables the approval of the catalogue.

As shown in Figure 5: Permissions, the Validator is responsible for the approval of the catalogue, whereas the Reviewer is responsible for confirming the approval of Catalogue(s) submitted by the Validator.

Not all the catalogues require a review process. The review is a concept connected to the framework contract. Each framework contract must be preconfigured in order to determine whether or not the catalogues belonging to it need to be reviewed.

The diagram below provides a view on the several states related to the validation of a Catalogue:

Figure 12: Validation workflow


Catalogue Activation

Before becoming "Active" a Catalogue might be in one of the following states:

• "Validation in progress" – when the "Review" set up is "Off";

• "Review in progress"– when the "Review" set up is "On".

The activation of a Catalogue relative to the validity period can meet the following scenarios:

• The Activation is confirmed before the Validity Start Date;

• The Activation is confirmed after the Validity Start Date but before the Validity End Date.

When the Activation is not confirmed before the Validity End Date, the catalogue will expire as explained below (catalogue expiration).

When the Activation is confirmed before the Validity Start Date, the Catalogue will become active as of the Validity Start Date.

When the Activation is confirmed after the Validity Start Date and before the Validity End Date, the Catalogue becomes Active immediately.

Catalogue Expiration

A Catalogue will automatically Expire only in "Active" state and when the:

• Validity End Date is exceeded (time); or an

• Updated version of the same Catalogue becomes "Active".

The status of the Catalogue will become "Expired" after the Expiry.

In the case when the Validity End Date is exceeded during the validation/review process, the Catalogue changes its status to "Out of date" and the User will need to perform an action to "Confirm the Expiry". This means, that depending on the status in which the Catalogue is before becoming "Out of Date":

• Validator can only "Confirm the Expiry" of a Catalogue in the Validation process

• Reviewer can only "Confirm the Expiry " of a Catalogue in the Review process

As a result of the "Confirm the Expiry" the Catalogue is "Rejected".

If a Catalogue becomes "Out of Date" while in the validation/review process, the Central Catalogue Management System should not allow the:

• Validator to Approve the Catalogue

• Reviewer to Confirm the Catalogue Approval


4.1.3.1. Validate Catalogue in the Presentation Layer The ValidateCatalogueController class is used by the application to handle the requests for the validate catalogue use case. It provides an interface which allows the end-user to execute atomic operations for the approval of the catalogue. In details the operations are the following:

o startValidation: starts the approval process;

o acceptValidation: flags the catalogue as accepted;

o rejectValidation: rejects the catalogue;

o confirmExpiry: rejects the catalogue when it is out-of-date;

o startReview: starts the review process;

o acceptReview: accepts the approval previously submitted by the Validator;

o rejectReview: rejects the approval previously submitted by the Validator;

The former actions can be performed based on the following factors:

(1) The user permissions/roles on the catalogue;

(2) The lifecycle status of the catalogue.

The table below shows the combinations of these factors explaining when a user can perform an action on catalogue in a given status:

Catalogue Statuses

Draft Validation in progress Candidate Active Review in progress Out of date

Validator • startValidation • acceptValidation

• rejectValidation

X X • confirmExpiry

Use

r rol

es

Reviewer X X • startReview • acceptReview

• rejectReview

• confirmExpiry

4.1.3.2. Validate Catalogue in the Business Layer The CatalogueFacade class exposes an interface to execute atomic operations for the approval of the catalogue. The CatalogueFacade class exposes the following methods:

o startValidation();

o acceptValidation();

o rejectValidation();

o confirmExpiry();

o startReview();

o acceptReview();

o rejectReview();

All these methods exposed by the CatalogueFacade are responsible for coordinating the classes belonging to the underlying layer in order to perform the actions on the catalogue and update the catalogue status.

The catalogue workflow is entirely managed by CCMS and the implementation is not based on the usage of an external workflow engine. The CatalogueWorkflowExecutionService is the main


class responsible for the workflow management; the entire workflow is described using a standard XML Spring file. The workflow is described as a set of statuses and, for each status, a set of possible transitions and activities are defined. Below an example of definition of a status belonging to the workflow:

…. <bean class="eu.cec.centralcatalogue.core.workflow.impl.CatalogueStatus" name="activeStatus" id="activeStatus"> <property name="status"><value>ACTIVE</value></property> <property name="transitionManager"> <bean class="eu.cec.centralcatalogue.core.workflow.impl.SimpleTransitionManager"> <property name="nextStatus"><value>EXPIRED</value></property> </bean> </property> <property name="activities"> <util:list> <ref bean="activateCatalogueActivity"/> <ref bean="activateCatalogueApplicationResponse"/> </util:list> </property> </bean>

….

Figure 13: Workflow status definition

The Figure 13: Workflow status definition shows how the ACTIVE status is defined. A catalogue in ACTIVE status can only become EXPIRED. If a more complex transition is required, CCMS offers different TransitionManager implementations (for instance a transition can be based on some process variables).

When the catalogue enters in the ACTIVE status, the list of activities, defined under the property named "activities", are executed.

The figure below shows the list of activities which are executed when the catalogue enters in a specific status:

Status Activities Description

DRAFT Notification sent to validator(s) An email is sent to the validators responsible for the validation of the catalogue.

CANDIDATE ACTIVE Notification sent to reviewer(s) An email is sent to the reviewers responsible for the approval of catalogue.

Notification sent to the supplier An email is sent to the supplier in order to inform him about the activation of the catalogue.

ACTIVE

Application response An application response document is generated and sent to the outbound queue.

REJECTED Notification sent to the supplier An email is sent to the supplier in order to inform him about the rejection of the catalogue.


Application response An application response document is generated and sent to the outbound queue.

Figure 14: Workflow activities


5. DATA VIEW

The following diagram shows a high level abstraction of the data model which must be implemented by the system:

Figure 15: CCMS Data Model

Below the three main entities of the CCMS data model are described:

• The Catalogue entity represents the catalogue sent by the supplier. It contains the header information (i.e. Seller Party, catalogue ID, etc.) always valid independently by the catalogue version.

• The CatalogueVersion entity contains the data directly connected to a single catalogue version. Moreover it is the entity which a single process instance of the workflow is linked to; the field "lifeCycleStatusCode" is used to determine in which workflow status the catalogue is. Each CatalogueVersion instance may contain a reference to the next version of the same catalogue; the latest version has no reference to the next version. Each catalogue version


instance must be linked to an instance of the ContractVersion entity which represents the framework contract.

• The Item entity represents the single catalogue line belonging to a given catalogue version. In order to guarantee a correct versioning mechanism for the items, they are associated to an existing CatalogueVersion instance. The main entities linked to the Item entity are the following:

– ItemIdentification: contains the information about the identification of the item. It means that different codes can be used by different parties (seller, manufacturer, customer, etc.) in order to identify the same item;

– ItemRelationship: contains the information about the relationships amongst the items belonging to the same catalogue. Different types of relationship can be defined (accessory, complementary, component, required, replacement);

– ItemClassification: contains the information about the classification of the items;

– ItemComparison: contains information used for comparing different items based on price, quantity or measurement;

– PhysicalAttribute: contains information concerning physical attributes of the item (height, weight, width, etc.);

– RequiredItemLocationQuantity: contains information about the properties of an item in relation to specific numbers and/or specific locations (mainly prices).

Refer to [REF13] for a complete mapping between the CCMS data model and UBL definitions.

e-PRIOR Software Architecture Document · PDF fileSoftware Architecture Document Date:...

Documents

Transcript of e-PRIOR Software Architecture Document · PDF fileSoftware Architecture Document Date:...