Auf dieser Seite finden Sie die Roadmap für die einzelnen Features in der Entwicklung! Zudem zu jedem Feature eine kurze Beschreibung und ob die Entwicklung in diesem Bereich begonnen hat.
|
Die Auftrennung von B2B by Practice in CORE & API ist eine der wichtigsten Einschnitte für dieses Release. Neben Stabilität und der Möglichkeit zu besseren Wartung, binden wir dadurch Entwickler aus dem Bereich Java an B2B by Practice. Der Großteil der heutigen Weiterentwicklungen in den Projekten kann jetzt durch mehr Personen erfüllt werden.
Der CORE von B2B by Practice enthält nach der Trennung folgende Komponenten:
Folgende Komponenten werden in der Version 2.0 nur noch in Extensions entwickt:
Die Workflow Engine wird komplett überarbeitet. In der Version 2.0 wird die WorkflowEngine über alle Transaktionen mit dem MessageContext des jeweiligen WorkflowContainers informiert. Dies bildet die Voraussetzung, dass die WorkflowEngine eine optimale Verarbeitung eines Channels erreichen oder unterstützten kann. Im Bereich B2BBP Development werden wir näher auf die Funktionen eingehen!
Neben der Optimierung der Verarbeitung der Channels, kann die WorkflowEngine ein Komplettdokumentation über den jeweiligen Channel geben. Dadurch können Customizing-Fehler früher visualiert, erkannt und behoben werden.
Ein weiterer wichtiger Punkt ist die Erweiterung der Exception-Hierarchie. Die WorkflowEngine wird zwischen System- und Anwendungsfehler unterscheiden können. Die Darstellung im Monitoring kann komplett und transparent durch die WorkflowEngine in Standardfällen übernommen werden.
Die neue ChannelDistribution wird mit einer veränderten Administrationsoberfläche bedient. Über diese wird es möglich sein, die einzelnen CD-Extensions zu verwalten. Neben den bestehenden Eingenschaften einer CD-Extension, werden weitere Eigenschaften hinzugefügt. Dadurch wird es möglich, Init-Parameter an die CD-Extensions zu übergeben. Für die Eigenschaften ".executeOnChannelId", ".registeredServiceIds" und ".skipChannelDistributionOnChannelId" können jetzt auch excludes definiert werden. Dadurch wird es beispeilsweise möglich, die CD-Extension für alle Channels außer ... zu definieren.
Durch die Initialisierung der CD-Extensions über Parameter, ist es eventuell sinnvoll, gleiche CD-Extensions mit unterschiedlicher Konfiguration auszuführen. In der Version 2.0 können CD-Extensions innerhalb einer CD-Instanz mehrfach ausgeführt werden.
Neben der API Dokumentation wird das Mittel zur Entwicklung im B2B by Practice Umfeld die 'B2B IDE' werden. B2B IDE ist eine Plugin-Sammlung für die Eclipse Plattform mit der man geführt gegen B2B by Practice Version 2.0 entwickeln kann. Der allgemeine Ansatz einer jeden Entwicklung in B2B by Practice besteht zunächst einmal auf die Konzeption einer Extension am Reissbrett. Hierfür verwenden wir Modelle, die eine Extension in der Funktionalität schon beschreibt, bevor sie implementiert wird. Ist das deskriptive Modell erstellt, wird daraus Coding erstellt. Sollten hier schon Fehler auftreten, ist die Entwicklung auch später nicht lauffähig.
Auf dem generierten Coding können dann die Implementierungen erfolgen. Nachdem die Entwicklungen abgeschlossen sind, können diese zu Deployment-Archiven (sog. Bundles) zusammengepackt werden. Die gekapselte Funktionalität (in Archiven) kann dann über den Update-Mechanismus in B2B by Practice hochgeladen werden und steht nach einer Aktivierung direkt zur Verfügung.
Design: Erstellen eines deskriptiven Modells Entwicklung : Implementierung der generierten Artefakte Packaging: Bündelung der Funktionalitäten in Bundles Deployment: Direktes hochladen in B2B aus der IDE/ Direktes hochladen auf das Update-Repository zur automatischen Verteilung in die einzelnen B2B Installationen.
Die Architektur von B2B by Practice wird in der Version 2.0 in CORE und API Anteile aufgegliedert. Dadurch werden viele der jetzigen Komponenten in Extensions ausgelagert. Die nachfolgenden Bereiche bilden die Extension Komponenten. Es soll kurz beschrieben werden, wofür die Extensions verwendet werden. Nach Ausprägung der API werden hier Beispiele der Entwicklung veröffentlicht
Actions kapseln Funktionalitäten, die von der WorkflowEngine ausgeführt werden sollen. Eine Action ist immer Bestandteil eines Channels!
'In Actions sollten keine Funktionalitäten eingebaut werden, die Kommunikation ausführen! Dies wird in Services untergebracht'
Wie schon erwähnt werden Services hauptsächlich für die Implementierung von Kommunikation verwendet. Sowohl für die Annahme als auch den Versand!
Es gibt aber auch eine Reihe von Services mit anderer Funktionalität:
Über Channel Distribution Extensions kann die Ermittlung eines Channels gesteuert werden. Dieses basiert meistens auf Informationen aus den jeweiligen Eingangsnachrichten, kann aber auf alle Parameter des WorkflowContainers (MessageContext) zurückgreifen.
Funktionalität, die zu einer konfigurierbaren Zeit oder turnusmäßig, ausgeführt werden soll. Der Job Scheduler ist ein Service, der die folgenden Funktionen automatisch mitbringt:
Die Formaterkennung ist eine zentrale Komponente in Nachrichteneingang. Diese kann jetzt als Extension in zwei Ausprägungen entwickelt werden.
1. Komplette Formaterkennung inkl. ChannelDistribution
Wenn die komplette Formaterkennung ausgetauscht werden soll, dann muss auch eine Channel Distribution neu entwicklet werden. Diese beiden Komponenten gehören in B2B by Practice zusammen.
2. Formaterkennung für Formate
Die Erweiterung der Formaterkennung um neue Formattypen ist wahrscheinlich häufiger gefordert. Momentan sind folgende Formate in B2B by Practice unterstützt:
Eine interessante Extension ist dieser Bereich. Hierdurch wird es den Entwicklern möglich sein, Erweiterungen auch in die UI einzubringen. Diese werden über sogenannte Flex Module in B2B by Practice eingebracht. Die Backend-Funktionalität (Datenbeschaffung) wird durch Remote Service realisiert.
1. Flex Modules
Flex ist eine Programmiersprache zur Realisierung von Anwendungen im Browser, die durch ein Flash-Plugin ausgeführt werden. Es gibt von Adbobe eine Entwicklungsumgebung für Flex, FlexBuilder!
2. Remote Service
Remote Services sind Java Klassen, die das IRemoteService Interface implementieren. Der Zugriff aus die Remote Service erfolgt aus der Flex Applikation über BlazeDS und einem RemoteServiceDispatcher! Typsichere Konvertierung der Objekte zwischen den beiden Welten wir sichergestellt!
Das Prunkstück der Version 1.4 2 wird in der Version 2.0 ebenfalls noch einmal überarbeitet. Ein Thema, welches in einem Forums-Thread zunächst noch einmal mit der Anwendergruppe disktuiert werden soll sind die Suchfelder! Weiter unten finden Sie den Link zum Forumseintrag. Die Suche im Nachrichtenmonitor wird nur noch gegen die B2B Suchmaschine ausgeführt. Die so ermittelten Ergebnisse werden mit Informationen aus der Datenbank angereichert und an den Client zurückgesendet. Es findet keine Filter der Ergebnisse mehr am Client statt. Hierdurch werden unerwünschte Wackler im Forntend vermieden und die Wartezeit deutlich verkürzt.
In der Version 2.0 können Sie bestimmen, welche Informationen aus den Eingangsnachrichten ermittelt und gespeichert werden sollen. Dadurch können auch in der Übersichtstabelle sehr viele Daten zur Anzeige gebracht werden. Diese sind nicht mehr zusammen anzeigbar. Daher wird es weitere Personalisierungsfunktionen geben, damit jeder Benutzer neben der Spaltenanordnung und -breite auch entscheiden kann, welche Spalten überhaupt angezeigt werden sollen.
Problem Filter und Suchfelder? Wie schon erwähnt werden in der Version 2.0 alle Filter zu Suchfeldern. Bei zunehmender Anzahl an Spalten und der Vorgabe, dass man in der neuen Version nach alle Spalten auch suchen kann, muss eine anderen Darstellung der Suchfelder realisiert werden. Diese Diskussion (das hat das Anwendertreffen gezeigt!) soll im Forum fortgeführt werden. Den Link zum Forumsbeitrag finden sie hier, sobald er vorhanden ist.
Die externen Funktionalitäten sollen in die Hauptanwendung unter Verwendung der Extension API "Remote Services/Flex Module" integriert werden. Folgende Funktionen sind hier gemeint:
Neben der Integration der Funktionalität (Aufruf des EDI Analyzers direkt aus dem Nachrichtenmonitor), können auch die B2B Berechtigungen hier verwendet werden.
Arbeitsvorräte bilden das zentrale Werkzeug in Version 2.0 zum Clearing von Datenaustauschprozessen. Der Nachrichtenmonitor rückt hierdurch in die zweite Reihe und dient als Backup zur Vollständigkeitskontrolle oder für Administratoren, die besondere Anforderungen an Auswertungen stellen.
Arbeitsvorräte definieren eine bestimmte Filterung der Gesamtdaten mit dem Ziel, die jenigen Vorfälle zu finden, für die eine Klärung erfolgen muss. Arbeitsvorräte werden in Standardarbeitsvorräte und konfigurierbare Arbeitsvorräte unterteilt.
'Berechtigungen werden automatisch auf die Arbeitsvorräte angewendet!'
Die Präsentation der Arbeitsvorräte wird in den nächsten Wochen ausgeprägt. Momentan tendieren wir zu einer Karteikarten Darstellung (Tabstrip). Screenshots folgen, sobald ein Prototyp vorhanden ist.