SOPERA Blog

SOPERA Support for EDI and EDIFACT

Recently, we’ve discovered - thanks to a number of customer requests - that support for EDI and EDIFACT is a must-have feature. Currently, with our SOPERA DI we are delivering the first version of our EDI/EDIFACT related components, based on an open source smooks framework. These components work quite well for simple EDI messages. You can configure the EDI mapping and read EDI messages into your SOPERA DI Jobs. We have already used them in a few customer cases and have learned quite a lot from it. Here are some of the major issues we encountered:

• You need to specify the mappings manually, even when processing standard EDI messages, for example, UN EDIFACT.
• It’s hard to read the UN/EDIFACT interchange that contains multiple messages of the same type, and it’s impossible to read UN/EDIFACT interchange with multiple messages of different type.
• The current state of components is not capable of writing out EDI files, only parsing/reading is supported to date.
• The tooling provided to read EDI messages inside the SOPERA DI needs to be improved. For example, we could display the message structure to simplify the mapping with a point-and-click feature.

At the same time the framework we were previously using for parsing EDI messages in SOPERA DI EDI components has made significant progress in the areas mentioned above allowing us now to take advantage of these improvements as well as to continue with our efforts to test and fix bugs. Here I would like to give you a short preview of the improvements we’ve made in this area.

UN/EDIFACT Mappings

The first area we improved is the manual definition of EDIFACT mapping files. This task can be quite tedious - one has to convert the UN/EDIFACT definitions into an XML-based mapping that can be used for EDI parsing. With the updated EDIFACT tooling you can get them automatically generated from UN definitions. Let us take for example the UN Customs cargo report message (CUSCAR). The picture below demonstrates this process:

Automated Mapping Generation

Here we take the CUSCAR definition which is available for download for example from within the package d99a.zip, and automatically generate XML Mappings according to the CUSCAR description from the UN. Now you can be sure all segments, segment groups, fields, and components are available in the mapping with all cardinalities as well as optional and mandatory flags. Moreover, since the ZIP file from the UN contains not only a single CUSCAR dialect definition but many others you will also get them packaged and ready to use.

UN/EDIFACT Inter-exchange processing

As you might know the EDI inter-exchange may contain multiple EDI messages of different types, each messages starts with the header segment that defines the message type (dialect), release year etc. For example, here is the header for the CUSCAR message:

UNB+UNOA:2+SENDER+SENDER+100421:0437+1918'
UNH+163477+CUSCAR:D:99A:UN:SCPRBL'

The second field of the UNH segment defines the dialect - here it’s CUSCAR released in the first part of the year 1999 (D99A) by the UN. The updated UN/EDIFACT parser is able to recognize individual messages as well as message dialects and dynamically chooses the appropriate mapping from the mapping JAR files generated before, as shown here:

Dynamic UN/EDIFACT Interexchange parsing

Writing out UN/EDIFACT files

Currently, our SOPERA DI EDI components do not support EDIFACT file generation. Basically, EDIFACT files are just simple text files, and one could simply use a plain template approach to generate EDI. However, we’d like to have additional semantic and syntax checks as well as validation checks. For this purpose we could use an EJC compiler as shown in this figure:

EDI-to-Java roundtrip

The basic idea is that we could generate a set of Java classes based on the UN/EDIFACT mapping files. These classes would then represent segments, segment groups or fields/components specified in the mapping file, and the best part is- you can use them to read EDI as well as write EDI out. It’s similar to the Java API for XML Data Binding, but in this case we bind the Java objects to the EDI content.

Improved UI for SOPERA DI Components

All of the features mentioned above are very useful but our experience shows us that we need to improve the user interface of SOPERA DI EDI components. Right now we are still in the planning and investigation phase. So if you think you have a nice feature proposal we would be glad to hear from you, just leave your comment on this blog post.

Conclusion

All in all with the new functions of the extended EDI processing we can provide a significantly improved user experience that will greatly simplify EDI processing. However, there is still some work to do, but what is clear right now is that all of it will be brought to you by SOPERA and the smooks team as an open source project so you are welcome to participate, contribute, and improve it.

Renat Zubairov Entwicklung, Strategie EDI, EDIFACT, smooks, SOPERA, SOPERA DI, Talend

We have new partners

Last year we launched the new SOPERA Partner Program. Our partners get earlier access to new product versions and technologies. They have the opportunity to give input to the SOPERA roadmap and release plans, and benefit from best practices in dedicated areas of application. Trainings to increase the technical know-how are included in the partner fee.

New Partners

Today we welcome our new partners:

• CapGemini
• CSC
• cologne intelligence
• saxonia
• senacor
• tarent
• USU AG
• Meyer Business Services

You can find more information about our Partner Program here.

Renat Zubairov Ereignisse, Management, Strategie Partner Program, Schlagwort hinzufügen, SOPERA Partners

Es war recht still die letzten Monate um die Eclipse SOA Intitative. Das lag hauptsächlich daran, dass große kommerzielle Vendoren kurz vor dem Start im Herbst 2009 aus der Industry Working Group zurückgezogen haben.

Ich denke, man sieht hier noch immer die Unsicherheit dieser Firmen im Umgang mit Open Source Projekten. Die verbliebenen Mitglieder Obeo, itemis und SOPERA, deren Geschäftsmodell auch eng mit Open Source Projekten verbunden ist, haben die Arbeit trotzdem fortgeführt. Schließlich trat die Firma Engineering, Italiens größter Systemintegrator, der Industry Group im Februar 2010 bei und gab mit den zwei neuen SOA-Projekten ( eBPM und eBAM) der ganzen Initiative ein neues zusätzliches Momentum. Deshalb wird die Eclipse SOA Industry Working Group nun mit einem halben Jahr Verzögerung diese Woche auf den SOA Days der Deutschen Post offiziell durch eine Keynote von Mike Milinkovich gestartet.

Ricco Deutscher Entwicklung, Management, Strategie eBAM, eBPM, Eclipse SOA

Extending our Reach

SOPERA’s SOA open source software is based on a building a community for developers. SOPERA has created a partner program to extend our ability to reach members of this community. Our partner pogram offers strategic alliances and enables us to offer customized and innovative solutions.

Types of Partnerships

SOPERA offers a partner program with various options for cooperation. Here is a short list of what our partner program covers:

• System Integrators
• Master Resellers
• Independent Software Vendors
• Technology Partners

For more information, see Partner Program.

Anne Aloysious Ereignisse, Strategie partner

Die Eclipse SOA Initiative tritt nun in die offizielle 30 tägige Proposal-Phase ein. Die Charter ist hier einsehbar. Folgende Gründungsmitglieder haben ihre verbindliche Teilnahme zugesagt (in alphabetischer Reihenfolge):

• itemis (Steering Committee, vertreten durch Wolfgang Neuhaus)
• obeo (Steering Committee, vertreten durch Stephane Drapeau)
• Progress Software (vertreten durch Oisin Hurley)
• Software AG (vertreten durch Prasad Yendluri)
• SOPERA (Steering Committee, vertreten durch Ricco Deutscher)

Der offizielle Start wird nach der Proposal-Phase erfolgen und bis dahin sind noch einige Dinge zu tun, wie z.B:

• die detaillierten Anforderungen der ersten beiden Meilensteine festzulegen und
• das erste komplette Eclipse SOA Platform Packet bis zum offiziellen Start bereitstellen.

Es zeichnet sich aber jetzt schon ab, dass der Umfang des ersten Eclipse SOA Platform Paketes zunächst klein sein wird.

Die Stärke der Eclipse Foundation – die IP-Sicherheit – kann in der Entwicklung allerdings auch ein Hemmnis sein. So kann z.B. aus diesem Grund die BPEL-Engine Apache ODE noch nicht als Teil der Eclipse SOA Platform ausgeliefert werden. Aus diesem Grund wird SOPERA eine Member Distro bereitstellen, die die Funktionalität der Eclipse SOA Platform um das Process Orchestration Feature erweitert. Andererseits möchten die Mitglieder sicherstellen, dass die Funktionalität der Platform auf der Tooling – und Runtime-Seite – in gleicher Geschwindigkeit und mit wechselseitiger Unterstützung wächst. Zum Beispiel gibt es heute schon einen Eclipse SCA-Editor, aber Swordfish unterstützt SCA noch nicht, daher wird SCA erst später Bestandteil der Platform sein. Obeo wird vor diesem Hintergrund eine Member Distro auf Basis von Tuscany bereitstellen.

Ricco Deutscher Strategie

Ich bin gerade vom ersten Eclipse Board Meeting in Europa zurück, dass in Berlin stattfand. Dabei hatte ich die Gelegenheit dem Board den neuesten Stand der Eclipse SOA Initiative zu präsentieren (Kopie der Präsentation hier). Diese Initiative hat sich seit dem SOPERA-Announcement auf der EclipseCON im März diesen Jahres enorm entwickelt. Aus der SOPERA Initiative wurde nunmehr eine Eclipse Initiative, weil sich zwei unerwartete Dinge ergeben haben:

1. Zu meinem großen Erstaunen teilen weitere Eclipse-Mitglieder unsere Vision und haben ihre Teilnahme angekündigt, und
2. die Foundation stellt seit Kurzem eine neue Organisationsform - die Industry Working Group - bereit, die die Ziele der Initiative organisatorisch sinnvoll abbilden kann. Das  Konstrukt der Industry Working Group erlaubt die Bildung von Sub-Konsortien innerhalb des Eclipse-Konstortiums mit eigenen Governance-Regeln und eigenem Branding. Nun, wo ich das Konstrukt erstmals verstanden habe, bin ich total begeistert davon und überzeugt, dass das es ein sehr großes Potential für die Eclipse-Foundation darstellt (Mike - die Credits gehen an Dich. Great Job!)

Zurück zur Eclipse SOA Initiative. Die Ziele dieser Initiative haben sich nicht geändert:

• Bereitstellung einer auf Equinox basierten, integrierten und erweiterbaren Eclipse SOA Platform inkl. Tooling und Runtime
• Förderung der Adoption dieser Platform durch Vendoren, System Integratoren und Distributoren
• Erreichung von Interoperabilität zwischen verschiedenen Produkten der teilnehmenden Vendoren

Dieses Ziele werden nunmehr durch zwei Maßnahmen innerhalb der Foundation erzielt:

1. Es wird ein neues Top-Level-Projekt “Eclipse SOA Platform” gebildet, das initial aus STP (dem Tooling) und Swordfish (der Runtime) besteht. Es soll das Zuhause für alle zukünftigen SOA Projekte werden (z.B. BPM, BAM, Registry/Repository). Dafür wurde eine neue Charter entwickelt. Das STP PMC hat dieser Charter bereits zugestimmt. Die Zustimmung des Boards wird bei nächster Gelegenheit eingeholt.
2. Es wird eine Eclipse SOA Industry Working Group (IWG) gegründet (Wir suchen noch einen coolen Nick name. Wer eine Idee hat, kann sie mir gern posten), die (a) die Anforderungen an die Eclipse SOA Platform definiert, (b) eine neue Marke für diese Platform entwickelt, und (c) messbare Kriterien festlegt, wer diese Marke wie nutzen darf. Diesen Brand sollen insbesondere auch von Nicht-Mitglieder wie ISVs und Systemintegratoren genutzt werden.

Diese Aufbauarbeit der letzten drei Monate war eine großartige Teamarbeit zusammen mit Oisin Hurley von Progress und Donald Smith von der Eclipse Management Organisation (Guys, es macht großen Spass mit Euch zusamenzuarbeiten!). Ich möchte mich an der Stelle auch für die Unterstützung bei Ralph Müller bedanken (Ralph - ich erinnere mich noch sehr gut an unser entscheidendes Meeting mit Mike am Frankfurter Flughafen. Danke für die Ausdauer mit mir!). In den nächsten wenigen Wochen wird sich herausstellen, wer die Gründungsfirmen neben SOPERA und Progress sein werden. Seit dem letzten Board Meeting ist jedoch klar, dass wir die kritische Masse an Gründungsmitgliedern erreicht haben. Wer das wird, wird demnächst hier publiziert. Stay tuned!

Ricco

Ricco Deutscher Strategie

SOPERA wird morgen auf der EclipseCON hier in Santa Clara seine neue Eclipse SOA Initiative (siehe Homepage und Pressemitteilung) ankündigen. Ziel dieser Initiative ist die Entwicklung einer integrierten und kohärenten SOA-Plattform innerhalb von Eclipse. Wo heute nur einzelne Komponenten vorhanden sind, die dazu noch über verschiedene Eclipse-Projekte wie Swordfish, STP, BPEL unkoordiniert verstreut sind, soll zukünftig ein integriertes Eclipse-Package zur Entwicklung von service-orientierten Applikationen auf der Eclipse-Homepage frei zum Download bereitstehen. Teil dieser Eclipse SOA Initiative ist die Entwicklung einer neuen Service Registry/Repository im Rahmen eines neuen Eclipse-Projektes, da alle heute vorhandenen Open-Source-Registry/Repository-Projekte für das Enterprise-Level ungeeignet sind.

Auch wenn diese Eclipse SOA Initiative zunächst eine SOPERA-Initiative ist, so suchen wir die Zusammenarbeit mit anderen SOA-interessierten Firmen und Eclipse-Mitgliedern. Eine solche Zusammenarbeit würde es erlauben, die entstehende Eclipse-SOA-Plattform noch schneller und noch näher an den Marktbedürfnissen zu entwickeln. Es gab gestern Abend mit dem EMO (Eclipse Management Organization) ein Gespräch zu der Frage, in welche organisatorische Form diese Initiative eingebettet werden könnte. Es scheint, das eine “Industry Working Group” für eine solche Initiative gut geeignet ist, da hier flexibel eigene Governance-Strukturen festgelegt werden können.

Wir erwarten bei den traditionellen Lizenz-Anbieter von SOA-Platformen auf die Eclipse SOA Initiative keine überschwengliche Begeisterung, da dadurch der Wert der kommerziellen Plattformen kanibalisiert werden könnte. Erste Gespräche mit Eclipse-Mitgliedern werden hier auf der EclipseCON stattfinden. Bei den Unternehmen auf der SOA-Nutzer-Seite stoßen wir nicht unerwartet auf sehr großes Interesse. SOPERA ist hier mit einigen Großkunden im Gespräch, die bereit sind, eine solche Initiative zu unterstützen.

Ricco Deutscher Strategie

Auf der Cebit präsentierten unter dem Dach der OSBF die Firmen SOPERA, Microsoft, 1&1, Corisecio und OpenXchange einen wegweisenden Prototypen einer heterogenen Application Cloud auf Basis eines Internet Service Buses (siehe OSBF-Presseerklärung). Das ist ein wichtiger Meilenstein für einen neuen Weg, wie Business Applikationen für Unternehmen flexibler und kostengünstiger nutzbar gemacht werden. Zukünftig werden große Teile der Applikationslandschaft von Unternehmen, die heute ausschließlich in dedizierten Rechenzentren betrieben werden, als Service aus einer Internet Cloud von verschiedenen Providern bezogen. Das wird mit Commodity Services wie Archiving und E-Mail beginnen, aber bald auch auf Kernapplikationen wie CRM übergreifen. Unternehmen, die diesen Weg nicht mitgehen, werden bald einen Wettbewerbsnachteil haben, da deren IT zu teuer und zu unflexibel sein wird.

Aber auch in einem solchen Szenario stellt sich die fundamentale Frage der Integration. Cloud Computing hat dabei über die traditionelle Applikationsintegration hinausgehende zusätzliche Anforderungen. Die Tatsache, dass Services von verschiedenen Providern bezogen werden können, erfordert ein Service-Level-Monitoring. Weiterhin müssen die verschiedenen Plattformen, auf denen die Services entwickelt und betrieben werden (hauptsächlich Java und . Net) völlig transparent sein. Es wird auch dazu kommen, dass ein Unternehmen für einen Service mehrere Provider nutzt, und die Auswahl des Providers dynamisch über die gerade für das Unternehmen benötigten Service Levels geschieht. Das sind Anforderungen, die der Internet Service Bus - der Enterprise Service Bus der Application Cloud - erfüllen muss. SOPERA hat mit dem auf der Cebit präsentierten Prototypen bewiesen, dass es wichtige Anforderungen eines Internet Service Bus bereits heute erfüllt. Dazu zählt:

• Eine dezentrale Bus-Architektur die Skalierbarkeit in der Cloud sicherstellt
• Native Implementierung in den beiden vorherrschenden Applikationsplattformen Java und .Net
• Eine dynamische, Policy-basierte Mediation zwischen Service-Provider und -Consumer

SOPERA ist damit bestens für den Zukunftsmarkt Cloud Computing positioniert.

Ricco Deutscher Strategie