On what does the interoperability solution of the UN/CEFACT CCTS rest?

The UN/CEFACT Core Components Technical Specification (CCTS and ISO 15000-5) is developed by the UN/CEFACT Techniques and Methodologies Group (TMG), one of the permanent working groups of the UN/CEFACT. The most important goal of the UN/CEFACT TMG is the development of information and communication technology specifications and recommendations for the other UN/CEFACT working groups. The UN/CEFACT TMG group also developed the UN/CEFACT Modelling Methodology (UMM).

What is the goal of the UN/CEFACT CCTS ?
The UN/CEFACT Core Components Technical Specification (CCTS) provides in a syntax-neutral methodology for the design and development of semantic building blocks.

The goal of the specification is to provide a solution oriented approach for the well-known interoperability question. For years the lack of information interoperability between Business supporting systems has been a restricting factor in the realization of inter-enterprise collaborative Business processes and data exchange.

The UN/CEFACT CCTS constitutes the basis for the development of a grammar that organizations can use to develop new Business vocabularies. Those new vocabularies contribute to improving and simplifying the way parties communicate with each other across Business boundaries (applications and systems) and domains (sectors). To eliminate the interoperability problems the use of one generic grammar language is advised.

The UN/CEFACT takes care of the development and maintenance of a universal Core Component Library (CCL) and Data Type Catalogue with free access for the Core Component community.

What boundary conditions apply ?
For a proper working of the CCTS concept all standards organizations need to ensure their core components are included in the Core Component Library (CCL) and/or need to open up their libraries to others.

At the moment only a few standards organizations have adopted and partially implemented the CCTS approach. OAGIS and OASIS Universal Business Language (UBL) took the CCTS as a basis for the development of their message libraries. Some other standards organizations that adopted the CCTS approach are RosettaNet, CIDX, HR-XML en ACORD.

What approach does the CCTS takes in solving the interoperability question ?
The approach of the Core Components Technical Specification is based on commonly accepted and publicitely available Core Components and derived Business Information Entities. The most atomic information parts for assembling the core components and information entities, up to a complete Business document, are the Core Data Types (CDT).

The foundation for the interoperability solution of the UN/CEFACT CCTS are the Core Data Types (CDTs) and the Business Data Types (BDTs) which are stored in the Data Type Catalogue of the UN/CEFACT. All other Core Components and Business Information Entities are based on these atomic information parts.

Given the fact that all standards organizations that adopted the CCTS approach have based their message libraries on these atomic information parts and are making use of the Data Type Catalogue the future of the CCTS looks promising.

The OAGIS and the OASIS UBL standards took over the Core Data Types and Business Data Types as a set of Unqualified Data Types (UDT) in addition to their own specific data types. However since the UN/CEFACT CCTS was developed only recently these organizations have not yet been able to incorporate all of the CCTS concepts. Although it should be mentioned that the OASIS UBL standard was ahead of the UN/CEFACT.

Key principes of the CCTS Data Types
There are two kinds of Data Types: Core Data Types (CDT) and Business Data Types (BDT).

The Core Data Types identify the most atomic pieces of Business information and should be considered as generic data types. Every Core Data Type consists of a Content Component and one or more Supplementary Components.

The Content Component is the carrier of the actual value and the Supplementary Component give meaning to this value. Every Content Component and Supplementary Component has a Primitive Type that sets the initial Value Domains. The Value Domain of the Content Component defines the set of permissible values for the Core Data Type but is constrained by its Supplementary Component.

The Core Data Types defines the value space for the Core Component (CC). The Business Data Types for the Business Information Entity (BIE).

Example:
The Core Data Type Amount.Type contains a Content Component that carries the value and a Supplementary Component that gives meaning to that value.

CDT = Amount. Type
Primitive = Decimal
Content Component = 12 (Amount. Content)
Supplementary Component = EUR (Amount. Currency. Code)

The Core Components Technical Specification provides a fixed list of Core Data Types in the Data Type Catalogue. The catalogue contains the list of the UN/CEFACT permissible Representation Terms, Core Data Types and Business Data Types.

The list of Core Data Types includes types such as Amount. Type, Binary. Object. Type, Code. Type, Date. Type, Date. Time. Type, Duration. Type, Graphic. Vector, Identifier. Type, etcetera.

Focus areas of the CCTS are:
- Core Components (CC's):
Core Components are semantic buidling blocks, conceptual in nature, that can be used for all aspects of data and information modelling.

- Business Information Entities (BIE's)
Business Information Entities are context-specific uses of conceptual core components within a specific business domain. BIE's are always derived from CC's.

Import startingpoint for the methodology is the use of the Dictionary Entry Name (DEN). This is the unique official name of the core component in the dictionary. The CCTS specifies that the dictionary content shall be in the English Language following the primary Oxford English Dictionary English spellings to assure unambiguous spelling.

The Core Components Technical Specification provides companies a semantic base for the support of different XML-languages for electronic communication. The CCTS enables semantic mapping of components between different libraries.

What is the status on solving the interoperability question ?
In the UBL Developers Community Mark Crawford answers my question How will CCTS improve the interoperability between one or more communication partners, standards and systems as follows:

"The Data Type interoperability is just one aspect of the interoperability of CCTS. People are referring to the base data types from CEFACT, but much more importantly, they are doing this in the development of their syntax neutral data models. The Data Types are the basis for both the conceptual and logical data models. The conceptual data model and semantic focus are the keys to interoperability as every logical data model is derived from a single ubiquituous data model."

In other words the CCTS aims at realizing universal semantic interoperability of Business Information through one single conceptual data model from which all other context-specific logical data models are derived.

This means that the necessary interoperability can only be obtained when all data models from the different standards are derived from the CCTS conceptual data model, next to the use of the Data Type Catalogue and the Core Component Library (CLL).

Likely this will not happen in the next few years because the impact is very extreme. I do not believe that standard organizations and others are willing to abandon their approaches and knowledge base in favor of interoperability. Other less extreme initiatives will soon be launched and build upon the CCTS or follow a new direction (web ontology).

One thing is sure, all of us are behind the idea that Informationinteroperability should be realized by using one common notion of the meaning of data but the way this will be done is not yet determined.

Once the selected principle can be incorporated in systems and applications then interoperability will be commonly accepted.

I will stay on top of the latest developments of interoperability and will soon be back with more.

Tags van Technorati: electronic data interchange,UDEF,CCTS,UN/CEFACT

Last update: 26-11-2011

Waarop berust de interoperabiliteitsoplossing van de UN/CEFACT CCTS ?

De UN/CEFACT Core Components Technical Specification (CCTS en ISO 15000-5) is ontwikkeld door de UN/CEFACT Techniques and Methodologies Group (TMG), één van de permanente werkgroepen van de UN/CEFACT. De voornaamste taak van de UN/CEFACT TMG is het ontwikkelen van informatie- en communicatietechnologie specificaties en aanbevelingen ten behoeve van de andere UN/CEFACT werkgroepen. De UN/CEFACT TMG groep heeft eveneens de UN/CEFACT Modelling Methodology (UMM) ontwikkeld.

Wat wordt beoogd met de UN/CEFACT CCTS ?
De UN/CEFACT Core Components Technical Specification (CCTS) voorziet in een syntax-neutrale methodologie voor het ontwerpen en ontwikkelen van een verzameling semantische bouwstenen.

De specificatie richt zich op het aanbieden van een oplossingsgerichte aanpak voor het alom bekende interoperabiliteitsvraagstuk. H et ontbreken van informatieinteroperabiliteit tussen bedrijfsondersteunende systemen is al jaren één van de beperkende factoren in de realisatie van inter-enterprise collaboratieve bedrijfsprocessen en gegevensuitwisseling.

De UN/CEFACT CCTS vormt de basis voor het ontwikkelen van een grammaticataal waarmee organisaties nieuwe woordenboeken - Business vocabulaires - kunnen ontwikkelen. Deze nieuwe woordenboeken dragen bij tot het verbeteren en vereenvoudigen van de wijze waarop partijen overheen bedrijfsgrenzen (applicaties en systemen) en domeinen (sectoren) met elkaar elektronisch gegevens kunnen uitwisselen. Om interoperabiliteitsproblemen voorgoed uit te bannen is het gebruik van één generieke grammaticataal aanbevolen.

De UN/CEFACT draagt zorg voor de ontwikkeling en het onderhoud van een universele Core Component Library (CCL) en Data Type Catalogue met gratis toegang voor de Core Component gemeenschap.

Welke randvoorwaarden gelden ?
Voor de goede werking van het CCTS concept dienen alle standaardisatieinstellingen hun core componenten op te laten nemen in de Core Component Library (CCL) en/of hun libraries open te stellen voor anderen.

Momenteel hebben slechts een aantal standaardisatieinstellingen de CCTS aanpak onderschreven en gedeeltelijk doorgevoerd. OAGIS en OASIS Universal Business Language (UBL) hebben CCTS als basis genomen voor de ontwikkeling van hun berichtenbibliotheken. Andere standaarden die de CCTS aanpak hebben overgenomen zijn ondermeer RosettaNet, CIDX, HR-XML en ACORD.

Welke benadering volgt de CCTS voor het oplossen van het interoperabiliteitsvraagstuk ?
De benadering van de Core Components Technical Specification gaat uit van algemeen geaccepteerde en publiekelijk beschikbare Core Components en daarop gebaseerde Business Information Entities. De meest elementaire informatiedeeltjes voor het assembleren van de core componenten en informatieentiteiten, tot en met een volledig bedrijfsdocument, zijn de Core Data Types (CDTs).

Het fundament voor de interoperabiliteitsoplossing van de UN/CEFACT Core Components Technical Specification wordt gevormd door de Core Data Types (CDTs) en de Business Data Types (BDTs) die zijn vastgelegd in de Data Type Catalogue van de UN/CEFACT. Al de andere Core Components en Business Information Entities zijn op deze elementaire informatiedeeltjes gebaseerd.

Het feit dat al de standaardisatieinstellingen die de CCTS aanpak hebben onderschreven hun berichtenbibliotheken eveneens baseren op deze elementaire informatiedeeltjes en gebruik maken van de Data Type Catalogue legt de basis voor de toekomst.

De OAGIS en de OASIS UBL standaarden hebben de Core Data Types en Business Data Types overgenomen als een verzameling van Unqualified Data Types (UDT) in aanvulling op de eigen specifieke data types. Aangezien de UN/CEFACT CCTS pas recent is ontwikkeld hebben deze instellingen de nodige achterstand in het inpassen van de CCTS concepten in hun standaarden. Het moet echter gezegd dat in feite de OASIS UBL standaard de voorloper is geweest van de UN/CEFACT CCTS.

Basisprincipes van de CCTS Data Types
Er zijn twee soorten Data Types: Core Data Types (CDT) en Business Data Types (BDT).

De Core Data Types identificeren de meest elementaire stukjes bedrijfsinformatie en worden beschouwd als generieke data types. Elke Core Data Type bestaat uit een Content Component en één of meer Supplementary Components.

De Content Component is de drager van de actuele waarde en de Supplementary Component geeft betekenis aan deze waarde. Elke Content Component en Supplementary Component is afgeleid van slechts één Primitive Type welke het Value Domain, de verzameling toegestane waarden, vastlegd. Het Value Domain van de Content Component bepaalt de verzameling van toegestane waarden van de Core Data Type die verder nog beperkt kunnen door de gedefinieerde Supplementary Components.

De Core Data Types bepalen het karakter van de inhoud van een Core Component (CC). De Business Data Types doen dat voor een Business Information Entity (BIE).

Voorbeeld:
Het Core Data Type <em>Amount.Type</em> bevat een Content Component die de waarde met zich meedraagt en een Supplementary Component die betekenis geeft aan de waarde.

CDT = Amount. Type
Primitive = Decimal
Content Component = 12 (Amount. Content)
Supplementary Component = EUR (Amount. Currency. Code)

De Core Components Technical Specification voorziet in een vaste lijst van Core Data Types opgenomen in de Data Type Catalogue. Deze catalogus bevat de lijst van door de UN/CEFACT toegestane Representation Terms, Core Data Types en Business Data Types.

De lijst van Core Data Types bevat ondermeer de types Amount. Type, Binary. Object. Type, Code. Type, Date. Type, Date. Time. Type, Duration. Type, Graphic. Vector, Identifier. Type, enzovoort.

Focusgebieden van de CCTS zijn:
De Core Component Technical Specification richt zich op twee gebieden:
- Core Components (CC's):
Core Components zijn de semantische bouwstenen, conceptueel van aard, voor het ontwikkelen van data- en informatiemodellen.

- Business Information Entities (BIE's):
Business Information Entities zijn context-specifieke toepassingen of afbeeldingen van conceptuele core components binnen een bedrijfsdomein. BIE's worden altijd afgeleid van CC's.

Belangrijk uitgangspunt voor de methodologie is het gebruik van de Dictionary Entry Name (DEN). Dit is de unieke officiële naam van een core component in het woordenboek. De CCTS schrijft voor dat voor de naamgeving (Dictionary Entry Name) van de Core Componenten de Oxford English Dictionary gevolgd dient te worden. Hetzelfde geldt voor de andere componenten uit de Core Component Technical Specification.

De Core Components Technical Specification biedt bedrijven een semantische basis voor de ondersteuning van verschillende XML-talen voor elektronische communicatie. Door het gebruik van CCTS kunnen semantisch equivalente componenten eenvoudiger gemapped worden tussen verschillende bibliotheken.

Hoe ver staat het met het oplossen van het interoperabiliteitsvraagstuk ?
In de UBL Developers Community antwoordt Mark Crawford op mijn vraag op welke wijze CCTS de interoperabiliteit tussen één of meer communicatiepartners, standaarden en systemen bevordert als volgt:

“CCTS richt zich op het bereiken van universele semantische interoperabiliteit van Business Information via één enkel conceptueel data model en daarvan afgeleid diverse contextspecifieke logische data modellen.”

Dit betekent dat de noodzakelijke interoperabiliteit alleen gerealiseerd kan worden wanneer naast het gebruik van de Data Type Catalogue en de Core Component Library (CCL) eveneens de datamodellen van de verschillende standaarden worden afgeleid van het CCTS conceptuele data model.

Vermoedelijk zal dit niet binnen nu en enkele jaren worden gerealiseerd omdat dit vrij ingrijpend is. Ik geloof niet dat de standaardisatieinstellingen en andere organisaties bereid zijn om hun gevolgde aanpak en knowledge base op te geven ten gunste van de interoperabiliteit. Er zullen andere iniatieven worden opgestart die minder ingrijpend zijn en verder borduren op de CCTS of een totaal andere invalshoek hanteren (web ontology).

Eén ding is zeker, we staan wel met zijn allen achter het idee dat Informatieinteroperabiliteit gerealiseerd moet worden door een gemeenschappelijk begrip van de betekenis van gegevens maar de wijze waarop dit tot stand moet komen is nog niet definitief bepaald.

Wanneer het toch ooit zover komt en het gekozen principe(s) ingebed kan worden in systemen en applicaties dan zal interoperabiliteit gemeengoed zijn. Ik blijf de ontwikkelingen op de voet volgen en zal hier binnenkort op doorgaan.

Tags van Technorati: electronic data interchange,UDEF,CCTS,UN/CEFACT

Last update: 26-11-2011

Short description of the UN/EDIFACT message structure

Extending Open Source tools with functionality for defining and executing message transformations from EDIFACT to other standards and back requires a good understanding of the UN/EDIFACT Standard.

Hereafter I will briefly explain the UN/EDIFACT standard and discuss the following topics:
- important character sets
- the different elements of the structure
- a description of the structure
- the position, status and repetition factor of the structure elements
- the compression rules

important character sets
- Segment terminator = apostrophe '

- Segment tag and data element separator = plus sign +

- Component data element separator = colon :

- Release character = question mark ? immediately preceding one of the characters ' + : ? restores their normal meaning.
Example: 10?+10=20 means 10+10=20

the structure elements
The structure of an EDIFACT message is fixed and contains a number of mandatory and conditional elements. The most important building block of an EDIFACT message is the segment and hence the structure is defined in segment tables. These tables show which segments are used in the message and the order in which the segments must occur.

A simple example of such a segment table looks as follows:

Segments that belong together can be grouped in a segment group. A segment group always contains a trigger segment and at least one or more segments or segment groups. The trigger segment is a mandatory segment and must appear once. The trigger segment is always the first segment in the group.

A segment is uniquely identified using a segment tag and the position in the message.

In the above example the segment with the segment tag RFF is a trigger segment of the segment group 1 and also of the segment group 3.

A segment is a collection of logically related stand-alone or composite data elements in a fixed, defined sequence. The segment BGM, see example below, contains two composite data elements and two stand-alone data elements. A composite data element contains a combination of several data elements.

description of the structure
The structure of an EDIFACT message consists of three group levels. These levels are often called envelopes. The start and end of an envelope is identified by a service segment. The segment tag of service segments start with the letters UN.

The three levels of the EDIFACT structure are:
- Interchange Envelope (mandatory)
- Functional Group Envelope (conditional)
- Message Envelope (mandatory)

The Interchange Envelope consists of the segments UNA, UNB and UNZ. The segment UNA Service String Advice is an optional segment and provides the capability to specify the use of different separators from the standard.

The segment UNB Interchange Header identifies the sender and receiver of a message. All the data within the Interchange Envelope are defined for one receiver. The segment UNZ Interchange Header closes the envelope.

The electronic document, the actual EDI message, contains the segments from UNH to UNT. A message always starts with a Message Header, the UNH segment, and ends with a Message Trailer, the UNT segment.

The segment UNH contains the Composite Data Element UNH-S009 Message Identifier with the message type, version number and the identification of the organization responsible for the message specification. The Data Element 0065 Message Type contains the message type. The message type is identified using a 6-letter word.

The service segment UNS Section Separator can also appear in the message part to make a clear distinction between the header, detail and summary sections. For the separation between header and detail sections the segment contains the value D and between the detail and the summary sections the value S.

The Functional Group Envelope is defined by the segments UNG and UNE. The use of the functional group envelope is mandatory for communication to and from North America. The functional group envelope provides the capability to include messages from different types in separate functional groups.

position, status and repetition factor
Segment groups, segments, composite data elements and data elements have a fixed position in the structure of an EDIFACT message. The position is represented by the position number. The position of segments and segment groups can be different for each message type.

The field Status (S) identifies the elements in the structure that are Mandatory or Conditional. When a segment is mandatory it should at least occur once.

The field Repetition (R) indicates the maximum number of times an element in the structure may repeat.

A Data Element is considered available when the data element contains a value of 1 character. A composite data element is considered available if at least one of the data elements is present. A segment is available when the segment tag is present and a segment group is available when the trigger segment is present.

Compression rules
The UN/EDIFACT standard was created when bandwidth was limited and therefore several compression rules were defined to ensure that messages are as compact as possible.

These compression rules are one of the rules that makes working with EDIFACT messages difficult as you will understand later on.

* exclusion of conditional segments by omission
Conditional segments containing no data shall be fully omitted.

* exclusion of conditional data elements in a segment by omission
If a conditional data element is omitted and is followed by another data element, its position shall be indicated by retention of its data element separator.

* exclusion of conditional data element in a segment by truncation
If one or more conditional data elements at the end of a segment are omitted, the segment may be truncated by the segment terminator. Contiguous trailing data element  separators are not required to be transmitted.

The last two data elements from the previous example are omitted because these do not contain a value.

These rules count also for data elements in a composite data element except that another separator is used.

* exclusion of conditional data elements in a composite data element by omission
* exclusion of conditional data elements in a composite data element by truncation

The full overview of the UN/EDIFACT Syntax Rules can be found on the website of the UN/ECE on the webpage UN/EDIFACT Syntax Rules.

Tags van Technorati: EDIFACT

Last update: 26-11-2011

Transformation of EDIFACT messages using Open Source tools

The United Nations Economic Commission for Europe UN/ECE started in the mid’ 80 with the development of the UN/EDIFACT (United Nations Electronic Data Interchange for Administration, Commerce and Transport) standard for EDI. In 1988 the UN/EDIFACT standard has been adopted by the International Organization for Standardization (ISO) under the ISO standard ISO 9735.

The UN/EDIFACT standard has gradually grown to the international standard for Electronic Data Interchange. But with the rise of XML standards EDIFACT is under pressure for several years now. However the UN/EDIFACT standard is still frequently being used and implemented globally.

The UN/EDIFACT standard has especially aimed, beside the syntax, on content standardization, the semantics. In it the real power of EDIFACT hides.

The XML standards have especially problems with functional standardization. A universal method for standardization like the Core Components from UN/CEFACT has not been generally accepted and implemented. Please read more in my bloart How do we solve the interoperability question ?

Because of this several incoherent and incompatible as well as fragmented standards arise.

The approach that is followed by developers of XML standards is separation of functionality and technique.

The past years especially the technique of XML has got all the attention and the number of Open Source tools for working with XML has increased tremendous. Open Source transformation tools such as XAware and Chainbuilder unfortunately do not support the UN/EDIFACT standard or related standards. The attention for the technique of XML is the main reason for this.

The need for the UN/EDIFACT support standard will remain for the next few years. People ask me on a regular basis when this functionality will become available. Open Source transformation tools that provide this capability will be adopted much faster. The need for commercial EDIFACT translation tools will disappear.

Potentially vendors of commercial transformation software will consider, probably this already happens now, to make their products available under an Open Source license. Companies like Sun and IBM could gain a significant market share in this field area on the Open Source market if they would open up their transformation tools for JCAPS (Sun) and WebSphere (IBM). The first steps in that direction are made. Sun Microsystems, the important sponsor behind the Open Source project OpenESB, has announced to incorporate components of OpenESB in Java CAPS in the future.

XAware and Chainbuilder could eventually become the standard transformation tool for OpenESB. I have put myself forward in the XAware community (as ‘sponsor’ in) driving this to realize EDIFACT transformation functions and perhaps in the meantime it is possible to realize a solution for Chainbuilder as well.

Tags: electronic data interchange, eclipse, data mapping tool, EDIFACT

Last update: 26-11-2011

Beknopte beschrijving van de UN/EDIFACT berichtstructuur

Het uitbreiden van Open Source gereedschappen met functionaliteit voor het definiëren en uitvoeren van berichttransformaties van EDIFACT naar andere standaarden en omgekeerd vereist een goed begrip van de UN/EDIFACT standaard.

Ik zal hierna beknopt de UN/EDIFACT Standaaard proberen uit te leggen. Achtereenvolgens zullen de volgende onderwerpen aan bod komen:
- belangrijke karaktertekens
- de verschillende structuurelementen
- een beschrijving van de structuur
- de positiebepaling, status en herhalende factor van structuurelementen
- de compressieregels

enkele belangrijke karaktertekens
- Segment einde teken = apostrophe '

- Segment tag en data element separator = plus sign +

- Component data element separator = colon :

- Release character = question mark ? herstelt de betekenis van het daaropvolgend teken

Voorbeeld: 10?+10=20 betekent 10+10=20

de structuurelementen
De structuur van een EDIFACT bericht is vastomlijnd en bestaat uit een aantal verplichte en optionele elementen. De belangrijkste bouwsteen van een EDIFACT bericht is het segment en de structuur waaraan een bericht moet voldoen is daarom vastgelegd in segment tabellen. Deze tabellen beschrijven welke segmenten in een bericht voorkomen en in welke volgorde.

Een eenvoudig voorbeeld van zo'n segment tabel ziet er als volgt uit:

Segmenten die bij elkaar horen kunnen worden gegroepeerd in een segment groep. Een segment groep bevat altijd een trigger segment en ten minste één of meer segmenten of segment groepen. Het trigger segment is een verplicht segment en moet eenmaal voorkomen. Het trigger segment is bovendien het eerste segment in de groep. Een segment wordt eenduidig geïdentificeerd door een segment tag en de positie in een bericht.

In bovenstaand voorbeeld is het segment met de segment tag RFF een trigger segment voor de segment groep 1 en eveneens voor de segment groep 3.

Een segment is een geordende verzameling van functioneel bij elkaar horende stand-alone of composite data elementen. Het segment BGM, zie voorbeeld hieronder, bestaat uit twee composite data elementen en twee stand-alone data elementen. Een composite data element is een samengesteld data element en bestaat uit een opeenvolging van data elementen.

beschrijving van de structuur
De structuur van een EDIFACT bericht voorziet in drie niveau's of group levels. Deze niveau's worden ook weleens enveloppes genoemd. Het begin en einde van een enveloppe wordt aangegeven door een service segment. Service segmenten zijn segmenten waarvan de segment tag start met de letters UN.

De drie niveau's waaruit een EDIFACT structuur kan worden opgebouwd zijn:
- Interchange Envelope (verplicht)
- Functional Group Envelope (optioneel)
- Message Envelope (verplicht)

De Interchange Envelope bestaat uit de segmenten UNA, UNB en UNZ. Het segment UNA Service String Advice is een optioneel segment en voorziet in de mogelijkheid om het gebruik van scheidingstekens die afwijken van de standaard tekenset te definiëren.

Het segment UNB Interchange Header identificeert de afzender en ontvanger van een bericht. Al de gegevens binnen de Interchange Envelope zijn bestemd voor eenzelfde ontvanger. Het segment UNZ Interchange Header sluit uiteindelijk de enveloppe.

Het elektronische document, het eigenlijke EDI bericht (Message), bestaat uit de segmenten UNH tot/met UNT. Een bericht begint altijd met een Message Header, het UNH segment, en eindigt met een Message Trailer, het UNT segment.

Het Segment UNH bevat het Composite Data Element UNH-S009 Message Identifier waarin het berichttype, het versienummer en de instantie of organisatie verantwoordelijk voor de berichtspecificatie is opgenomen. Het Data Element 0065 Message Type bevat het berichttype. Het berichttype wordt geïdentificeerd door een zes-letterwoord.

Verder kan het service segment UNS Section Separator eveneens voorkomen in het berichtdeel om een duidelijke scheiding tussen de header, detail en summary secties te identificeren. Voor de scheiding tussen header en detail secties bevat het segment de waarde D en tussen de detail en summary secties de waarde S.

De Functional Group Envelope wordt gedefinieerd door de segmenten UNG en UNE. Het gebruik van de functional group envelope zou verplicht zijn voor de communicatie van en naar Noord Amerika. Deze groep maakt het mogelijk om verschillende berichten van hetzelfde type op te nemen en te groeperen in een EDIFACT bericht maar wordt niet of nauwelijks gebruikt. Er kunnen meerdere functionele groepen worden opgenomen met elk een verzameling berichten van hetzelfde type.

positiebepaling, status en herhalende factor
Binnen de structuur van een EDIFACT bericht hebben zowel segment groepen, segmenten, compostie data elementen als data elementen een vaste positie weergeven door een positienummer. De positie van segmenten en segment groepen in een bericht kan per berichttype verschillen.

Via het veld Status (S) wordt aangegeven welke onderdelen in de structuur verplicht (Mandatory) of optioneel (Conditional) zijn. Als een segment verplicht is dan moet het segment minimaal eenmaal voorkomen.

Via het veld Repetition (R) wordt aangegeven hoe vaak een onderdeel in de structuur maximaal mag voorkomen of herhaald worden.

Een Data Element wordt als aanwezig beschouwd van zodra het data element een waarde bevat bestaande uit 1 karakter. Een composite data element is aanwezig als ten minste één van de data elementen beschikbaar is. Een segment is aanwezig wanneer de segment tag aanwezig is en een segment groep is aanwezig als het trigger segment aanwezig is.

compressieregels
Aangezien EDIFACT is ontstaan in het tijdperk dat bandbreedte een kostbaar goed was zijn een aantal compressieregels gedefinieerd die ervoor moeten zorgen dat berichten zo compact mogelijk worden opgesteld.

Deze compressieregels maken het werken met EDIFACT berichten complex zoals u dadelijk zult merken.

* uitsluiting van optionele segmenten door weglating
Optionele segmenten die geen waarde krijgen moeten volledig achterwege gelaten worden.

* uitsluiting van optionele data elementen binnen een segment door weglating (omission)
Als een optioneel data element geen waarde krijgt en gevolgd wordt door een ander data element dan moet de positie van het optioneel data element wordt aangegeven door het data element scheidingsteken.

* uitsluiting van optionele data elementen binnen een segment door inkorting (truncation)
Als één of meer optionele data elementen geen waarde krijgen en voorkomen aan het eind van een segment dan mogen deze achterwege gelaten worden. Het segment mag worden afgesloten met het segment einde teken - de segment terminator. Opeenvolgende achterliggende data element scheidingtekens moeten niet gecommuniceerd worden.

De laatste twee data elementen uit voorgaande voorbeeld worden weggelaten omdat deze geen waarde hebben gekregen.

In principe gelden de bovenstaande twee regels eveneens voor data elementen in een composite data element met dien verstande dat een ander scheidingsteken gebruikt wordt.

* uitsluiting van optionele data elementen binnen een composite data element door weglating (omission)
* uitsluiting van optionele data elementen binnen een composite data element door inkorting (truncation)

Het volledige overzicht van de UN/EDIFACT Syntax Regels kunt u terugvinden op de website van de UN/ECE onder de webpagina UN/EDIFACT Syntax Rules.

Tags van Technorati: EDIFACT

Last update: 26-11-2011

Installatie van Eclipse Subversive

Het Eclipse Subversive project richt zich op het beschikbaar maken van Subversion (SVN) functionaliteit in de Eclipse workbench. Subversive maakt het mogelijk om op dezelfde wijze als CVS (Concurrent Versions System) met repositories te werken. Subversion is net als Concurrent Versions System een versie controle beheersysteem voor het beheren van de broncode van programma's.

Voorheen moest u Subclipse, de Subversion plug-in van Tigris, installeren wanneer u gebruik wilde maken van Subversion functionaliteit in Eclipse. Op termijn zal Eclipse Subversive waarschijnlijk volledig worden geïntegreerd in de standaard Eclipse distributie.

Voordat u Eclipse Subversive installeert moet u zorgen dat Eclipse Mylyn is geïnstalleerd. Volg daarvoor de instructies in mijn bloart Installatie van Eclipse Mylyn.

Wanneer u Eclipse hebt opgestart kunt u Subversive installeren via het menu Help > Software Updates > Find and Install.

Selecteer Search for new features to install en in het dialoogscherm Install klik op de knop New Remote Site.

In het dialoogscherm New Update Site moet u de gegevens van de update site invoeren:
Naam: Subversive Update Manager Site
URL: http://download.eclipse.org/technology/subversive/0.7/update-site/

Klik op de knop OK om verder te gaan.

Klik daarna op de knop Finish voor het openen van het dialoogscherm Updates.

Vink de node Subversive aan en klik op de knop Next.

Accepteer de licentievoorwaarden en klik op de knop Next.

Daarna kunt u de locatie van de plugin's instellen als u niet wil dat deze in uw standaard Eclipse omgeving worden geïnstalleerd.

Nadat de installatie is afgerond moet Eclipse opnieuw opgestart worden.

Open het menu Help en dan ziet u dat de menuoptie Subversive is toegevoegd onder Software Updates.

Om met Subversive te kunnen werken zult u een Subversive SVN Connector moeten installeren. De Subversive plug-in en Subversive SVN Connectors worden gedistribueerd via verschillende updates sites. Installeer nu de Subversive SVN Connectors.

Open het menu Help > Software Updates > Find and Install.

Selecteer Search for new features to install en in het dialoogscherm Install
klik op de knop New Remote Site.
Open het menu Help

Selecteer Search for new features to install en in het dialoogscherm Install klik op de knop New Remote Site.

In het dialoogscherm New Update Site moet u de gegevens van de update site invoeren:
Naam: Subversive SVN Connectors Update Manager Site
URL: http://www.polarion.org/projects/subversive/download/eclipse/2.0/update-site/

Klik op de knop OK om verder te gaan.

Klik daarna op de knop Finish voor het openen van het dialoogscherm Updates.

Open achtereenvolgens de node Subversive SVN Connectors Update Manager Site en de node Subversive SVN Connectors. Selecteer de Connectors Native JavaHL x.y.z Implementation en JavaHL x.y.z Win32 Binaries aan.

Klik op de knop Next.

Accepteer de licentievoorwaarden en klik op de knop Next.

Daarna kunt u de locatie van de plugin's instellen als u niet wil dat deze in uw standaard Eclipse omgeving worden geïnstalleerd.

Nadat de installatie is afgerond moet Eclipse opnieuw opgestart worden.

Nu moet u nog onder Preferences controleren of de een Subversive SVN Connector is geselecteerd. Open het menu Window en selecteer de menuoptie Preferences.

Ga naar de node Team en selecteer de node SVN.

Controleer onder het tabblad SVN Connector een connector is geselecteerd: de Native JavaHL of de default SVN Kit.

Tags van Technorati: eclipse

Last update: 3-12-2011

Installatie van Eclipse Mylyn

Het Eclipse Mylyn is een taak-gerichte interface voor Eclipse met als doel het verhogen van de productiviteit van ontwikkelaars. Mylyn zorgt ervoor dat de ontwikkelaar direct toegang heeft tot informatie relevant voor het werk waar deze mee bezig is. Tevens voorziet Mylyn in functionaliteit voor het opvolgen van taken. Taken kunnen lokaal worden opgeslagen maar eveneens in een webgebaseerde repository zoals Bugzilla, Trac of Jira.

Wanneer u Eclipse hebt opgestart kunt u Mylyn installeren via het menu Help > Software Updates > Find and Install.

Selecteer Search for new features to install en in het dialoogscherm Install klik op de knop New Remote Site.

In het dialoogscherm New Update Site moet u de gegevens van de update site invoeren:
Naam: Mylyn Update Manager Site
URL: http://download.eclipse.org/tools/mylyn/update/weekly/e3.3/

Klik op de knop OK om verder te gaan.

Klik daarna op de knop Finish voor het openen van het dialoogscherm Updates.

Vink de node Mylyn aan en klik op de knop Next.

Accepteer de licentievoorwaarden en klik op de knop Next.

Daarna kunt u de locatie van de plugin's instellen als u niet wil dat deze in uw standaard Eclipse omgeving worden geïnstalleerd.

Nadat de installatie is afgerond moet Eclipse opnieuw opgestart worden.

Tags van Technorati: eclipse

Last update: 3-12-2011