CHAPTER 1: FUNCTIONALITIES OVERVIEW

Babelway Platform is first B2B integration Software-as-a-Service. It enables to quickly and cost-effectively automate B2B flows such as EDI messages and electronic invoices across all customers, suppliers, and partners. Leveraging the SaaS model, Babelway help to streamline the deployment, maintenance and monitoring of B2B exchanges giving greater confidence and control over business process. Because Babelway is a cloud-powered integration platform, it offers quick and cost-effective integration to SaaS and on premise applications. This means that client can achieve significantly improved data management, more efficient processes, lower enterprise costs, and better resource allocation.

 

Babelway services are fully available on-demand via a web-browser. There is no software or hardware to buy and maintain in-house, but yet Babelway is still under the full control of its users.

 

This chapter briefly describes the main functionalities of the software

 

Building channels

A channel is the collection of components that must be assembled within Babelway in order to organize an automatic data flow from an external system A to another external system B. The key components are

(1) the way in which Babelway is interfaced with system A, called the “gateway IN”,

(2) the way in which system A formats data, called the “message IN”

(3) the format in which system B wants to receive data, called the “message OUT”

(4) the way in which Babelway is interfaced with system B, called the “gateway OUT”

In building channels, Babelway contains the following functionalities:

 

Configuring communication gateways.

Users select how Babelway will communicate with external systems A and B. The communication protocol used with system A can of course be different from the communication protocol used with system B. Users can choose from a range of communication protocols, including:

 

• AS2:  this a communication standard largely used in retail to secure communication over the Internet.
• Ftp client: to set-up an FTP client accessing an external FTP server
• Ftp server: to configure the FTP server receiving incoming messages or to place outgoing messages
• Email: to set-up a new Email address to receive incoming messages or to send outgoing messages
• Web gateway: to set-up a website access to upload incoming messages or to download outgoing messages
• SOAP gateway:  to set-up a SOAP gateway (SOAP client) to send outgoing messages to a SOAP server.

Once the communication technology has been selected, users then fill in the template with the technical parameters that will be used to establish the connection between Babelway and the external system.

 

If certificates are an element of the communication protocol (eg. AS/2 or FTPs), users will incorporate the external system certificate as a technical parameter. Users will provide the corresponding Babelway certificate to the external system. (See the relevant chapter for details of security and certificate management)

 

Note: each Babelway user has its own set of gateway addresses or locators. External systems are therefore connected to individual Babelway users, not to Babelway in general.

Defining a message definition.

Users select the format amongst the following options

• CSV:  to define a character-delimited flat file with constant record definition (data is in columns)
• EDIFACT: to define a new message in EDIFACT format
• X12: to define a new message in X12 format
• MS Excel: to define a new message in MS Excel
• XML, based on XSD or samples
• Flat files, delimited of fixed length
• IDoc xml or flat files
• Many more…

Users will then upload an example of a message in this format. The system will automatically provide an XML version, as well as a visual representation in a hierarchical tree structure.

 

Creating transformation.

Creating transformation rules between the message IN and the message OUT.

Users can create the transformation rules using the drag&drop interface tool. Users can create correspondences between the message IN and the message OUT by dragging and dropping message fields from left to right.

 

For more complex transformation operations, users have a portfolio of standard operations they can call upon (concatenation, date formatting, etc.). More advanced users can also define new standard operations using the xpath syntax or xslt functions.

 

 

Creating validation rules

Users can define validation rules to be applied on incoming and/or outgoing messages. For example, validation can make the presence of values in some fields mandatory or make them correspond to a pre-set of values. Validation is particularly useful to prevent that an external system received messages that it cannot process automatically.

 

Signing outgoing messages

Users can configure channels such that outgoing messages are signed using a dedicated advanced certificate and if the outgoing format enables such signature (must be PDF or ZIP format). (See the relevant chapter for details of security and certificate management).

 

Creating lookup tables

Users can define and load tables of values, called look-up tables, which are used during the transformation process to change an incoming value into a corresponding outgoing value. An illustrative application of look-up tables is to enable a buyer and a supplier to use different product codes to identify similar products (e.g. GTIN codes versus internal codification).

 

Building test cases

Users can build test cases of their channels. The test cases enable users to check the result of their work on message formats and transformation prior to deploying a channel into the production environment.

 

Managing routing across channels

Messages originating from a common source but going to various external systems must be routed. Users can define routing rules based on message content items or on message context.

 

Managing notifications

For each individual channel, users can build automatic notifications that will send an email to a specified address upon the arrival of a new message. Notified users can be different if the message is successfully processed or an error is generated. Notification can also be sent to another channel for further processing.

 

Avoiding rework thanks to the catalogue

Gateway parameters, message formats, transformation and validation rules are created during the channel building process. Each of these items can be re-used in the building of a subsequent channel. This is organized via what we call the catalogue, the place where all new items are listed.

 

Users populate a new channel from the items available in their catalogue. This catalogue enriches itself progressively each time new channels are built. When users decide to source an item from the catalogue, they make a choice to use the same instance or to duplicate it. This choice is important when making changes to channels. If channels share the same instance of an item, a change in one channel will impact all other channels using the same item.

 

Note: Babelway will soon enable users to open up their catalogue to other selected Babelway users, so that channel items created by one user can be re-used by another user. Functionalities will include the secure management of access rights, the possibility of charging for the use of catalogue items and the possibility of tracking and measuring the usage of catalogue items.

 

Activating and deploying channel updates

Users decide which channels are under construction and which must be activated upon deployment in the production environment of Babelway.

 

Tracking messages

Messages that flow through the user environment can be tracked and traced. Users have access to any message stored, in all its forms (before, during and after transformation) together with contextual information such as time of entry, time of exist, status, as well as relevant security-related information such as certificates and signatures.

Problem resolution

Messages that are in error can be accessed directly for manual correction and resubmitted in a channel. In this case a new message is created and the message status of the original message is changed to ‘Error Closed’.

 

A function to massively resubmit messages is also available to the user.

 

Long term archiving

The messages stays accessible online to user during the whole retention period, as configured in the environment settings or overwritten in the channel configuration.

 

During this period, the entire information about the message are kept, including the inbound and outbound messages, all intermediate formats as well as the metadata and processing traces.

 

Managing Alerts

Multiple events generate alerts. For example, an alert is created when a FTP polling to a remote server cannot be completed due to a connection timeout.

 

Alerts provide detailed information to users, as well as tools for resolution management.

 

Account management

The account management function includes the following services:

 

Users management

The administrator of an account can provide other users with access to one of its environments. Access rights are as follows:

 

• Account ADMIN: All right at the Account level.
• Environment FULL_ACCESS: All right at the Environment level.
• Environment HUB_DEFINITION: Generally speaking allow to view and update existing information at the Environment level. This data dependent
• Environment OPERATIONS: Only access the monitoring section of the system.
• Environment PORTAL USER: Only access document belonging to a specific list of partners.

 

environments Management

An account can be made up of any number of different environments. It can be useful to build channels in separate environments if

 

• different people should have access rights; or
• message storage duration should be differentiated; or
• performance expectations are different
• security requirements demand it
• there is a need for a test environment

 

Performance management

Each environment has a default processing capacity. The default processing capacity is allocated by Babelway to meet the default service level agreement towards users.

 

Users can increase their processing capacity in multiple increments of the default processing capacity. By doing this, users can double, triple, quadruple, etc. the processing capacity of their environment and therefore handle very large amount of simultaneous data flows, without being dependent on the general consumption of capacity in other Babelway environments.

 

Storage management

As a default option, Babelway stores messages for a period of 3 months. Users can select the ‘long-term archiving’ option which provides storage for any period of time up to 12 years.

 

Other terms of storage (shorter or longer) may be accommodated individually.

 

CHAPTER 2: QUALITY AND SECURITY MANAGEMENT

Audits and Quality management

SOC2 Type 2

Babelway complies with SOC2 Type 2 norm since 2013 and is yearly audited by Deloitte for Security, Availability, Processing Integrity, Confidentiality, and Privacy. This conformity is equivalent to the past SAS70 norm, which certifies the quality of the Security Procedures.

 

 

 

 

ISO 27001

Babelway has put in place an Information Security Management System (ISMS) compliant with ISO27001 guidelines. Babelway’s policy regarding security can be consulted online (https://www.babelway.com/?s=security+policy) . The system ensures processes are in place to meet the policy’s objectives.

Currently Babelway has not seek the ISO27001 certification.

 

 

e-Invoicing Legal Compliancy

From May to October 2008, Professor Jos Dumortier, an internationally recognised expert in the field of legal electronic signatures, audited the Babelway solution and checked its compliance with the legal requirements imposed by the EU Directive about electronic invoicing. Professor Jean-Jacques Quisquater, an expert in cryptography, assisted in the project by giving his views on the specific use of cryptographic technologies made by Babelway.

 

The project resulted in an audit report which concluded that Babelway meets the legal obligations regarding e-invoicing. The signature made available to Babelway customers is indeed an ‘advanced signature’ in the legal sense since it fulfils the 4 conditions, namely:

• It is uniquely linked to the signatory
• It identifies the signatory
• It is created in such a way that the signatories can maintain it under their sole control
• It is linked to the data in such a way that any change is detectable

 

 

Note: Babelway offers an ‘advanced signature’ to transfer and store messages. Customers can use Babelway in a way that can guarantee the authenticity of origin and the integrity of the message. However, Babelway does not accept responsibility for the way in which customers assemble specific channels, establish interchange contracts with their partners and connect their own systems to their Babelway environment. Babelway stresses to customers that it their responsibility to check their own usage of Babelway and to assess whether it is compatible with their local regulatory environments.

 

 

 

Hosting and redundancy

Babelway infrastructure is hosted externally. Babelway has agreements with 2 hosting providers:

 

• Combell, a recognized Belgian hosting company. Combell uses the physical premises of LCL, located in Diegem, Belgium. Premises have been audited by an independent consultant mandated by Babelway.
• Amazon, a recognized International company. Babelway subscribes to the Amazon Web Service (AWS) offering whereby Babelway has access to virtual servers “on-demand”. Servers are physically located in Ireland.

 

To maximize availability and reliability, not only has Babelway contracted on strict terms with reliable partners but it has also installed redundancy between its 2 data centers. In the event of downtime of one of the 2 data centers, Babelway can switch all data traffic to the other data center.

 

Limitations of the redundancy are:

• Web interfaces (human access to user environments) has an active node in Combell only, with a real-time passive backup on Amazon. In case of unavailability of the Combell infrastructure, messaging services can continue but human tracking or maintenance is not available, until the passive node is activated.
• Gateways to external systems based on physical IP addressing would also be interrupted. We recommend that users use URL locators instead of IP addressing wherever possible.

 

 

 

Private Cloud

The processing and archiving of messages are achieved by separate component called the ‘messaging engine’. The messaging engine are self-sufficient to process messages, even if temporarily disconnected from the web interface.

 

This approach technically allows customers of Babelway to host their messaging themselves while still using the unique Software-as-a-Service. This could be important to some customers if security considerations require them to control the messaging servers themselves or to have servers physically located in some specific geographic territory, for example.

 

Default Geographic location

Babelway customers hosted on the shared infrastructure have the possibility to choose the geographic location of their messaging engine between an EU location or a US location.

 

Infrastructure management

Our hosting providers have demonstrated to Babelway that they managed infrastructure according to our (SOC2 and ISO 27001) expectations levels.

 

Amazon AWS security processes are described at http://aws.amazon.com. Babelway subscribes to EC2 and S3 services. Amazon AWS has the security certification SAS70 type II. Amazon cannot access Babelway data in any way. All data communication, storage and back-ups are encrypted. Encryption is made using a 2048bits private key created by Babelway and stored on Babelway server file system, with access restricted to the super user (root), a member of Babelway management.

 

Combell security processes are described at http://www.combell.com/en/. Combell employees do not have access privileges to Babelway servers.

 

The components (database, application server, gateways, etc.) of the infrastructure within each data centre have their own fail-over mechanism.

 

Babelway also provides to its customers private messaging engine, located in their datacenter of choice. Currently, Babelway operates messaging engines in AWS both in Europe and United States as well as in partner location in France in the AZNetwork datacenter.

 

Software management

 

Babelway software development is in Java programming language using XML and XSLT for data manipulation, Javascript and JQuery for the web front-end. The infrastructure run linux and uses PostgreSQL.

 

These components have been integrated into an extensive development program which began in October 2006. Our technical developments are centrally managed from our base in Belgium. We have developed a very precise expertise on highly specific topics such as scalability, database optimization, ergonomy, cryptography, processing performance, XML and EDIFACT standards, etc with recognized specialists in each of these fields and usually for short, highly focused missions.

 

Software development follows the Scrum framework for software and other platform development. Our sprint horizon are 2 weeks.

 

Data security

To ensure the total data independence between environments, Babelway software strictly controls data access using isolation techniques.

 

The system is based on RBAC (role-based access control) principles. Each software layer (presentation, application, business and data) performs its own security enforcement.

 

 

Audit Trail and traceability

All accesses to environment and customer data are logged in an audit trail. The audit trail is using a separate business logic to insure independence of the regular business logic. It cannot be modified by Babelway support agent. The audit trail is proactively inspected on a monthly basis for critical operation and odd usage patterns.

 

 

Monitoring

Monitoring of systems and applications are performed using different mechanisms:

• An external monitoring tool is used to test the availability and the performance of the application from a customer point of view. This system also includes a 24/7 alerting mechanism to the mobile device of operator in charge. An escalation process is also in place to insure proper handling of issues.
• An internal monitoring tool is used to test the availability and performance of the different components of the system. The Operations Manual provided in annex describes the set of monitored items
• A positive & reactive monitoring able to alert the Operation Manager when a situation requires some attention (for instance, a message entering the system and not delivered in the SLA window)

All tools are collecting information, generating statistics and deliver alert if needed. Issues and bugs encountered are logged and tracked for further reference and follow up.

 

Security Certificates

Babelway uses the following security certificates:

 

Babelway qualified certificate

Babelway uses the Belgian electronic identity card (eID) of designated members of the Board of Directors of Babelway as the Babelway qualified certificates of Babelway. The Babelway qualified certificate is used in signing chain timestamps in the message archives.

 

User environment advanced certificates

A pair of “root” keys is generated by Babelway for each user environment on a secure machine, not connected to the network. The public key is included in a self-signed “root” user-environment certificate and stored in the environment keystore. The private key remains in a separate keystore on the secure machine.

 

The user-environment certificate is sent to the Babelway security environment and stored as any other message, guaranteeing its integrity and timestamping (see archiving section below)

 

Babelway creates 3 pairs of keys for each environment and, using the user-environment root certificate, associates them with 3 environment certificates:

• A transfer pair, generated on the secure machine and stored in the keystore of the user environment. This certificate can be used by customers to sign outgoing emails with a structured file attached (EDI method) or to sign PDF or ZIP files that contain a message and are sent via an unsecured network (e-signature method)
• A storage pair, generated on the secure machine and stored on the user environment. The public key is included in a storage certificate signed by the user-environment root certificate. This certificate is used systematically to sign all stored messages of the user environment.
• An encrypting pair, generated on the secure machine and stored on the user environment. The public key is included in an encryption certificate signed by the user-environment root certificate. This certificate is used systematically to encrypt all stored messages of the user environment.

 

Babelway SSL certificate

Secure transfer certificate, associated with Babelway servers and certified by Thawte (Verisign). This certificate guarantees authenticity and confidentiality for exchanges using protocols: Web (https), SOAP (https), FTPs and FTPs Servers, AS/2 (https layer), whatever the customer environment performing the document exchange.

 

Babelway SSH certificate

Secure transfer certificate, used for exchanges using the sFTP protocol. This certificate is self-generated by Babelway with Babelway as the root authority. The certificate is ‘manually’ accepted by the exchange partner during the set-up of the sFTP connection.

 

Babelway AS/2 certificate

Secure transfer certificate, used for exchanges using the AS/2protocol. This certificate is self-generated by Babelway with Babelway as the root authority. The certificate is ‘manually’ exchanged between partners during the set-up of the AS/2 connection.

 

In addition to Babelway certificates, users can include/exclude external systems certificate in their own trusted certificate list (keystore).

 

Keystore management

Each user environment has its own keystore. This keystore keeps all the keys and certificates necessary for the runtime of the environment. It also contains the trusted external systems certificates. Users can add or delete trusted certificates. Users have no access to user environment private keys.

 

The keystore is based on recognized cryptographic standards. Access is protected with a password system with multiple layers.

 

 

Transfer security

Users have multiple options in order to securely send outgoing messages.

 

• They can use a protocol secured with one (or more) network certificate (SSL, SSH or AS/2).
• They can sign outgoing messages (PDF or ZIP formats) with their user-environment transfer certificate
• They can sign emails with their user-environment transfer certificate.

 

 

Archiving security

Each flow of message through a Babelway channel creates multiple files:

• the message as it existed when entering a channel of the user environment;
• the message as it existed when exiting a channel of the user environment;
• possible intermediary (XML) versions of the message between entry and exit.

 

A flow through a single channel creates a single ‘message record’ where individual files and their signatures are grouped.

 

The following process is used to guarantee the integrity of the stored files.

All files are signed using the storage certificate of the user environment using the SHA512 and RSA algorithms. The signature is hashed (SHA512) and the result is kept for the chain mechanism described below. Optionally, users can upload an encryption key that is used to encrypt stored files to insure that Babelway doesn’t have access to the content anymore. The file is then encrypted with the encryption certificate of the user environment using the AES256 algorithm. The encrypted file is then stored.

 

For each stored file, there is the following contextual data:

• an ID (sequence number)
• the date and time of the storage
• the “hash” of the signature created with the storage certificate
• the user environment ID number
• hash of the contextual data of the previously stored message
• the hash of the message is kept as ‘index’ for easy message retrieval
• the full signature is also kept for complete future validation

 

At regular intervals, in order to split the chain into easier to work chunk, Babelway signs the hash of the contextual data of the last available message with its qualified certificate. This is time-stamped by a trustworthy timestamp authority. At the same time, Babelway requests a validity proof for the Babelway qualified certificate from the Belgian authority (Citizen CA).

 

The chain makes it impossible for an individual user or for Babelway to change any stored element without breaking the chain and therefore making it detectable.

 

 

Proving authenticity of origin and integrity

Users of Babelway can demonstrate the authenticity of origin and the integrity of messages flowing through their environment as follows:

 

If users are using the transfer certificate, the public key or its footprint of their “root” environment certificate must be included in the interchange contract that Babelway users sign with their business partners. This explicitly shows the agreement of the parties to trust exchanges between themselves using this specific Babelway user environment certificate. It should be noted that:

• The fact that user environments on Babelway are unrelated to each other (no common certification authority) provides additional security in the sense that accepting exchanges with one Babelway environment does not imply accepting exchanges with all Babelway environments. Each B2B relationship must be individually certified between the parties. Users are responsible for informing their business partners of changes in the validity of their certificates.
• The absence of a trusted third party has no influence on the validity of the signature as an advanced signature. The parties have certified the identity of their counterpart through the interchange agreement (bilateral agreement).
• The chain mechanism in the storage system of Babelway guarantees (to users as well as to the tax authorities, for example) that messages have not been tampered with by anyone, including Babelway.

 

To verify the authenticity and the integrity of a specific file:

• The message record page in the user environment includes the decrypted file, the hash of the signature, the certificate of the storage public key of the user environment, the sequence number of the file, the sequence number of the user environment root certificate, the previous and next authenticated timestamp
• The previous and next authenticated timestamp must verified
• The chain is recreated between the 2 timestamps by re-hashing the contextual data of each stored file. This certifies the stored hash of the storage signature.
• The conformity of the message is verified. In particular,
  • The signature hash should be recalculated and checked against the stored hash for the message.
  • Check the signature of the storage key by the root certificate
  • Check the presence of the root certificate in the storage system and its conformity following the same process
  • Check the signature

 

This verification process guarantees that

• The message has been processed by a specified user environment on Babelway and on the date which is stated
• The message has not been modified since its signature

 

 

CHAPTER 3: USER SUPPORT

Helpdesk

The human monitoring function provides helpdesk support to users on working days.

Any request or issue reported is acknowledged within 15 minutes. It is given a support alert number and a reply is provided within 1 hour at the latest.

 

The support agents are distributed among 3 different levels, each one having his own expertise field. Below is a non-exhaustive list of examples of issues, distributed according to the level structure:

 

Level 1. This is where all support tickets begin. This level is able to provide:

• Assistance and help on system
• Messages follow-up (message not sent/received, message is in error)
• Basic troubleshooting like issue in mappings
• …

Level 2. If an issue cannot be resolved in level 1, it will be escalated to level 2. This level is able to solve issue like:

• Protocol incompatibility
• Problem linked to bug in the application code
• …

Level 3. Issues that cannot be resolved at level 2 will be escalated to level 3.

• Access to server logs and operating system
• Database queries
• …

 

Training

Babelway developed the Babel Academy. These are generic and specific training sessions provided by Babelway senior staff in Babelway premises or on-line.

 

Professional services

Customers can call upon Babelway professional services to support them with on-boarding partners, designing new channels, developing internal or external communication plans and generally execute projects in relation to the exploitation of the Babelway platform.

For each project, Babelway and the customer agree on a scope and a price based on man-day prices referenced in the pricelist. Account management and generally interventions requiring human involvement are defined with each customer within the scope of Babelway professional services.

 

Network of partners

Babelway develops and entertains a network of partners with specific capabilities in geographic regions, industrial sectors or technical domains. These partners can also be called upon in some customer projects.

Download this whitepaper in PDF format