Open Source und unsere Public API
Die B2B by Practice ist zu Teilen ein Open Source Produkt und untersteht dem ständigen Wandel. Auf Grund von Kundenanforderungen und projektgetriebenen Entwicklungen, sowie aber auch produktseitigen Erweiterungen und Umstrukturierungen kann es zu Änderungen von öffentlichen Methoden kommen.
Technische Herausforderungen
Die folgenden, wichtigen Erweiterungen unserer B2B by Practice dienen als Beispiele, durch welche Umstrukturierungen notwendig wurden und weiterhin werden:
- Spring-Integration
- Die B2B beinhaltet nun Teile des Spring-Frameworks, was uns bei weiteren Entwicklungen die Arbeit erleichtert und weitere Möglichkeiten schafft.
- UI-Umstellung
- Wir arbeiten an der Ablösung der Adobe Flex-Oberflächen und der Anbindung neuer Angular/HTML5-Oberflächen. Dabei werden u.A. Spring REST Controller verwendet.
- EAI-Funktionalität
- Die EAI-Funktionalitäten z.B. im Bereich von Webservices wurden erweitert (Stichwort AS4).
Public API
Im Maven-Modul /core/org.b2bbp.apiwurden inzwischen wichtige Klassen und Interfaces zusammengefasst, welche sich nicht oder nur mit deutlicher Ankündigung ändern werden. Gegen diese API zu entwickeln ist also sehr selten Änderungen unterworfen.
Entwicklung gegen unsere API
Einige Kunden nutzen den Open Source Part der B2B, um ihre eigene Funktionalität selbst zu implementieren und diese in Form von JAR-Dateien/eigenen Bibliotheken mit in das Deployment aufzunehmen. Eine Alternative ist die Bereitstellung an NLI als Contribution.
Leider wird die Variante der selbst implementierten Funktionalität mit Hinzufügen von Bibliotheken oft nicht abgesichert. Es werden beim Deployment regelmäßig die gleichen JAR-Dateien ins Deployment gelegt, ohne sie vorher neu zu compilieren.
Wie bereits erläutert, unterliegt unsere Software beständiger Änderung. Eine regelmäßige Prüfung externe Bibliotheken ist also notwendig, um nicht im produktiven Betrieb durch Laufzeitfehler behindert zu werden. Eigener Code sollte compiliert und geprüft werden. Aufrufe von Elementen, welche mit @Deprecated markiert wurden, müssen ernst genommen und entfernt bzw. ersetzt werden.
Deprecated gesetzte Elemente können von uns i. A. in einem folgenden Release entfernt werden. Desweiteren führen wir in der B2B auch die Markierung @DeprecationInfo, die als Typen alternativ auch den DeprecationType UNADVISED tragen kann. Elemente, die mit diesen Typ markiert wurden, werden von uns nicht weiter unterstützt. Ihre weitere Verwendung wird daher von uns nicht empfohlen und auch als Systemfehler geloggt. Da wir allerdings mittelfristig ihre Funktionalität nicht ersetzen werden, stehen diese (noch) nicht in Gefahr bei einem kommenden Release entfernt zu werden.
B2B zusammen mit eigenem Code in Maven bauen
Wenn man wie empfohlen eine eigene Entwicklung mit jedem B2B Release neu baut, kann dieser Prozess durch Maven vereinfacht und automatisiert werden. Insbesondere können somit Compile-Fehler noch vor dem Deployment entdeckt werden.
Vorraussetzung ist, dass der NLI Nexus via Maven erreichbar ist. Dieser muss zunächst freigeschaltet werden.
Angenommen die Firma Colen möchte eine Action für die B2B entwickeln, diese aber nicht per Contribution einpflegen sondern selbst verwalten. Sie erstellt und baut dafür ein Java Maven Projekt com.colen.b2b-actions mit folgender Abhängigkeit:
<dependency>
<groupId>org.b2bbp</groupId>
<artifactId>org.b2bbp.api</artifactId>
<version>1.14.0_1.4</version>
</dependency>
Mit Hilfe eines weiteren eigenen Maven Projekts com.colen.b2b-war kann automatisch die gesamte b2bbp-engine.war inklusive der eigenen Action gebaut werden; folgende Pom hat das Projekt zum vollen Build:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.colen</groupId>
<artifactId>com.colen.b2b-war</artifactId>
<version>1.0</version>
<packaging>war</packaging>
<properties>
<b2b.version>1.14.0_1.4</b2b.version>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<dependencies>
<dependency>
<groupId>com.nextlevel.b2b</groupId>
<artifactId>tomcat-war</artifactId>
<!-- an dieser Stelle kann auch ein Spezialbuild angegeben werden, z.B. tomcat-cas -->
<version>${b2b.version}</version>
<type>war</type>
</dependency>
<dependency>
<groupId>com.colen</groupId>
<artifactId>com.colen.b2b-actions</artifactId>
<version>1.0</version>
</dependency>
</dependencies>
<build>
<finalName>b2bbp-engine</finalName>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>3.2.2</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
</plugins>
</build>
</project>
Das Build Projekt com.colen.b2b-war hat sowohl eine Abhängigkeit auf die B2B, als auch auf das eigene Actions Projekt com.colen.b2b-actions.
Wenn nun ein neuer B2B Release veröffentlicht wird, müssen nacheinander beide Projekte gebaut werden, wobei in den Poms der beiden Projekte die Versionsnummer der B2B aktualisiert werden muss. Dieser Vorgang lässt sich vereinfachen, wenn beide Projekte zu einem Multi-Modul Projekt zusammengefasst werden, welches einheitlich die B2B-Versionsnummer verwaltet.
Es kann sich außerdem als nützlich erweisen, die Versionsnummer der eigenen Projekte mit der Versionsnummer der B2B synchron zu halten.
B2B Abhängigkeiten nutzen
Angenommen in com.colen.b2b-actions sollen weitere Abhängigkeiten genutzt werden, die auch im B2B Core genutzt werden, z.B. edi.util zum Verarbeiten von Edifact Nachrichten. Dann empfiehlt es sich, dass diese Abhängigkeiten in der gleichen Version eingebunden werden, in der sie auch im B2B-Core genutzt werden. Hierfür kann das B2B-Core-Dependency-Management eingebunden werden:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.b2bbp</groupId>
<artifactId>core</artifactId>
<version>${b2b.core.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
Nun müssen die Versionsnummern der Abhängigkeiten des Cores nicht mehr manuell gepflegt werden.
Neuerdings kann der Core in einer anderen Version vorliegen als die Versionsnummer der B2B-war. Um nicht manuell die Core Version jedesmal ermitteln zu müssen, kann stattdessen auch das DependencyManagement der ganzen B2B genutzt werden:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.nextlevel.b2b</groupId>
<artifactId>distro</artifactId>
<version>${b2b.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>