Code, Entwicklung, PHP, WordPress

WordPress und Magento – ein Lösungsansatz

WordPress wird recht häufig parallel zu Shops eingesetzt. Das hat viele Gründe; einer ist, dass Google frischen Content mag. Außerdem haben Shops häufig das generelle Problem, dass sie ziemlich Text-arm sind, da können Blogs für die Suchmaschinenoptimierung helfen.

In einem Projekt für einen neuen Shop auf Magento-Basis stand ich vor Kurzem vor genau dieser Aufgabe: ein Blog sollte aufgesetzt werden. Natürlich vom Look & Feel her an den Shop angelehnt. Also musste ein eigenes Theme her, so weit so gut. Aber es sollten auch einige Elemente des Shops im Blog genutzt werden. Zum einen die Menü-Struktur, die in diesem Shop den Kategorien entspricht. Zum anderen solche Dinge wie Footer, ein Bildwechsler und so weiter.

In diesem Artikel stelle ich vor, wie wir das Menü aus dem Shop im Blog verwenden. Die Idee funktioniert aber auch mit eigentlich allen denkbaren anderen Elementen des Magento-Shops, z. B. Produkte, Preise, Bewertungen, Warenkorb, Single-Sign-On mit dem Kundenkonto des Shops … eben alles, was man sich so an schönen Features überlegen könnte.
Weiterlesen

Standard
Entwicklung

Applikationen mit SAP verbinden

Es gibt verschiedene Methoden um unterschiedliche Applikationen mit SAP-Software zu verbinden. Die verschiedenen Möglichkeiten sind unterschiedlich gewachsen und werden in Zukunft auch unterschiedlich gepflegt bzw. ist die Weiterentwicklung eingestellt.
Die Folgende Übersicht soll die möglichen Schnittstellen ein wenig näher erläutern und somit eine Übersicht der Möglichkeiten ins SAP darstellen.

Manuelle Datenpflege

manuellAls erste Möglichkeit besteht darin, die Daten händisch in das System zu pflegen. Dies ist in vielen Unternehmensbereichen nicht selten, auch wenn es wenig effektiv ist, so bringt es zumindest Arbeitsplätze ins Unternehmen. Die Fehleranfälligkeit ist ebenso groß. Schnell kommt es zu Inkonstistenzen zwischen System SAP und Applikation.

Kopplung über IDocs

Intermediate Document (IDoc): SAP-Standardformat zum elektronischen Datenaustausch zwischen Systemen
Hierbei werden vorhandene oder neue Softwarebausteine im SAP genutzt. Sie sorgen für den Austausch der Daten. Alle SAP-Module können IDocs lesen und schreiben/ exportieren.
Die Daten werden mittels IDoc an das andere System übertragen und werden dort in ein spezifisches Format geschrieben, abhängig vom Host. Die Routine zum Lesen der Daten müssen natürlich in jeder Applikation erstellt werden.
Der Austausch der Daten erfolgt im einfachsten Fall über ein vereinbartes Verzeichnis, alternativ könne Protokolle wie ftp und http eingesetzt werden. Die größte Verbreitung der IDocs erfolgt jedoch über das SAP-eigene Protokoll RFC (Remote Function Call – ist eine SAP-Schnittstellenprotokoll, das auf CPI-C (Die Common Program Interface Communication beschreibt den Datenaustausch zwischen verschiedenen Programmen. Die Dateien werden mit CPI-C „verpackt“.) beruht, Damit wird die Programmierung von Kommunikationsabläufen zwischen Systemen wesentlich vereinfacht).

Die Daten werden in einer lesbaren Datei versendet, somit besteht die Möglichkeit, dass potenziell kritische Daten manipuliert bzw. gelesen werden können. Dies ist natürlich im Unternehmen selten erwünscht. Hierbei sollte aber berücksichtigt werden, in wie weit werden die Daten an ‚Außenstehende’ weiter gegeben oder befindet sich der Datenaustausch in einem geschützten Netz.
Ein weiterer Nachteil besteht in der mangelnden Fehlerbehandlung. Fehlerhafte Übergaben oder Fehler im IDoc selbst werden nicht an den Erzeuger der Daten gegeben. Ein Monitoring ist nur durch eine eigene Fehlerbehandlung möglich, die vom Anwender erstellt wird. Diese führt zu einem schlechten Händling, denn sie muss immer angepasst werden, es entsteht eine Abhängigkeit zwischen Sender um Empfänger.

Remote Function Call (RFC)

RFCMit Hilfe von RFC werden Aufgaben eines bestehenden Systems an ein anderes System verlagert. Das andere System stellt die Funktion, die das bestehende System nutzen möchte zur Verfügung. Sowohl Client als auch Server können ein SAP-System sein. Es werden Funktionsbausteine innerhalb des R/3-Systems aufgerufen, wodurch der Datentransport in Fremdsysteme und SAP-Systeme möglich ist und somit die Daten in einer anderen Programmiersprache zu Verfügung zu haben. Um einen Funktionsbaustein aufrufen zu könne, muss dieser in der Funktionsbibliothek des SAP-Systems als RFC-fähig definiert sein.
Mit RFCs kann aus diversen Sprachen heraus kommuniziert werden, beispielsweise gibt es viele Anwendungen in C und VB. Ebenso ist die Verwendung von php möglich. Ermöglicht wird dies durch einen Open Source Project – SAPRFC. Es werden Klassen für php4 und php5 bereitgestellt. Zusätzlich kann ein RFC Server Programm geschrieben werden, dass dann vom R/3-System aufgerufen wird.

Business API (BAPI)

Unter BAPIs verstht man standardisierte Schnittstellen von SAP. Mit Hilfe dieser BAPIs kann man von externen Anwendungen auf das SAP-System zugreifen (siehe RFC). Ein BAPI ist ein Funktionsbaustein, der RFC-fähig ist und zusätzliche Eigenschaften mitbringt. Der Unterschied zwischen einem BAPI und einem Funktionsbaustein besteht darin, dass der Funktionsumfang fest definiert ist, das es definierte Input-/ Output-Parameter gibt, dass der Baustein in der Regel zustandslos ist, funktionsorientiert gestaltet und die Parameter sind über Versionswechsel hinweg konstant.

Java Connector

Der JCO erlaubt einen bidirektionalen Datenaustausch, insofern eine Java-Anwendung auf dem zu verbindenden System läuft.

Läuft in der anzubindenden Applikation kein Java, muss eine zusätzliche Kopplung zwischen der Applikation und dem JCO-Adapter auf SAP-Seite entwickelt werden. Ein zusätzlicher Prozess mit erheblichen Mehrkosten.
Aber selbst wenn die Applikation eine J2EE-Anwendung ist, dann gibt es Probleme. Der JCO wurde nicht explizit für J2EE entwickelt, deshalb müssen Entwickler gegen Vorgaben der Spezifikation des Enterprise Java Beans (EJBs) verstoßen. Beispielsweise erfordert der JCO statische Methoden. Alternativ könnte man einen J2EE-konformen Adapter einsetzen (z.B. Librados), welcher Intern einen JCO besitzt. (mehr Information und beispiele dazu gibt es im Artikel „Anbindung von SAP R/3 über die J2EE Connector-Architektur“)
Die Typüberprüfung findet erst zur Laufzeit statt, dadurch müssen alle Tests im Vorfeld stattfinden.

Allerdings muss man sagen, dass seit ERP-Lösung R/3 Version 4.7 eine weitere bessere Möglichkeit besteht. Ab dieser Version steht SAPs Web Application Server bereit, in der ABAP-Version. Dieser stellt eine Reihe von Diensten bereit, um das SAP-System zu koppeln. Nun können gängige Java-Methoden angewandt werden. Zum beispiel kann mit http oder SOAP gekoppelt werden.
Ab Version 6.20 des Web-AS gibt es einen JAVA-Web-AS. Auf diesem Server können Anwendungen nach J2EE-Standard laufen.

Business Connector (BC)

Gleich vorweg, der BC wird in Zukunft nicht mehr weiter entwickelt. Vorhandene Prozesse und Strukturen müssen auf die Exchange Infrastructure (XI) umstellen.

Der BC wurde entwickelt um externe Partner an das System anzubinden. Ein Mapping ist mit Hilfe von XML möglich. Neben der gängigen RFC-Schnittstelle werden htpp, ftp und smtp unterstützt. Die Architektur ist relativ einfach, wobei das Tool an sich sehr mächtig ist und dabei wenige Ressourcen benötigt. Die Anwendung ist Java-basierend und läuft als Webanwendung.

Exchange Infrastructure (XI)

xi nachrichtDie XI ist derzeit in der Version 3 auf dem Markt und soll die zentrale Schnittstelle im SAP werden. Ziel der XI ist es, als zentrale Plattform zur Verfügung zu stehen und verschiedene Schnittstellen über eine einheitliche Technologie zu verbinden.
Die Integrationslösung XI verarbeitet und überträgt Nachrichten. Die Nachricht wird als XI-konforme SOAP-Nachricht versandt. Die XI ermöglicht es, die zu verwendeten Daten in eine Form zu konvertieren, die das Zielsystem versteht. Über einen Adapter wird diese erzeugte Nachricht über einen Adapter an das Zielsystem übergeben. Auf diese Weise wird die Integration verschiedener Applikationen zentralisiert. Die Abhängigkeiten zwischen den Systemen sind klar erkennbar und können jederzeit verändert und gewartet werden.
Außerdem ist es möglich mit Hilfe der XI Geschäftsprozesse zu modellieren, grafisch. Andere Systeme werden damit über die SOAP-Nachricht integriert.

Ein Vorteil ist das Monitoring der XI. Kommt es beispielsweise zu Fehlern bei der Übertragung, versucht der Integration Broker die Nachricht noch einmal zu versenden. Messages können durch den User manuell editiert werden.
Kann eine Nachricht nicht zugestellt werden, so wird eine Fehlernachricht erstellt mit der die Quelle reagieren kann. Im Weiteren steht mit der XI eine Technologie bereit, sie die Prozesse mit Hilfe von Standards definiert und offene Schnittstellen ermöglicht bei großer Modularität.

Die Reaktion der Quelle ist nicht unproblematisch und führt ist zu Problemen.
Der Ressourcenbedarf der XI ist relativ hoch und nicht so performant wie der Business Connnector. Da die XI relativ neu ist, ist ausschließlich ein Unicode-System verfügbar, auch dies führt zu Problemen mit älteren Hardwaresystemen. Die XI benötigt also eine leistungsstarke Hardware und eine große Datenbank.

Standard
Entwicklung

Anforderung an Unternehmensapplikationen

Eine Applikation zu programmieren, die den hohen Anforderungen eines oder sogar mehrerer Unternehmen gerecht wird, ist schwer. Durch die Integration von Partnern, Kunden und Lieferanten werden die Probleme, welche gelöst werden müssen, zunehmend komplexer.
Um diesen Anforderungen gerecht zu werden, sind bestimmte Grundanforderungen zu erfüllen. Sie sind nur lösbar, indem eigenständige Module in eine hoch entwickelte E-Business-Plattform integriert werden, quasi eine übergreifend genutzte Entwicklungs- und Laufzeitplattform, die sich den speziellen Wünschen der Unternehmen anpasst. Durch die unterschiedlichen Module können sich Entwickler auf die Realisierung der eigentlichen Aufgabe im relativ kleinen Rahmen konzentrieren. Ein Entwicklerteam muss also nicht alle Anforderungen gleichzeitig erfüllen. Somit läuft es auch nicht Gefahr, das eigentliche Ziel des Projektes aus den Augen zu verlieren. Wesentliche Anforderungen an solch eine Plattform sind:

  • Durch die verschiedenen Hardware- und Betriebssysteme muss die genutzte Plattform die Ablauffähigkeit der Software sicherstellen. Sie muss alle vorhandenen Datenbanksysteme unterstützen und mögliche Einschränkungen auf ein System vermeiden.
  • Viele Nutzer müssen simultan an der Applikation arbeiten können. Sie muss über schnelle und langsame Netzwerkverbindungen erreichbar sein. Oft ist das Umfeld, in dem die Applikation genutzt wird, im internationalen Rahmen tätig, so dass verschiedene Sprachen notwendig sind.
  • Die Anwender müssen durch die Software authentifiziert werden. Individuelle Zugriffsberechtigung auf die unterschiedlichen Module und deren Funktion werden vergeben.
  • Die Verwaltung verschiedener Versionen sollte gewährleistet sein. Ebenso muss die Entwicklung in großen Teams möglich sein.
  • Alle systemseitigen und eigenen Programmelemente müssen aus Produktivitätsgründen für andere Entwickler wieder verwendbar sein.
  • Die zahlreichen technischen und betriebswirtschaftlichen Basisdienste und Funktionen müssen innerhalb der Applikation nach Bereichen und Themen strukturiert werden. Nur so ist das System überschaubar und verwaltbar.
Standard
Entwicklung

Schnittstellen

Grundlagen

Als Schnittstellen bezeichnet man „Türen“, durch die Daten zwischen einem System und seiner Umwelt ausgetauscht werden. Die Schnittstelle stellt ein Teil des Systems dar, welches dem Austausch von Informationen mit anderen Systemen dient. Die Informationen können dabei in verschiedener Form vorliegen. Schnittstellen werden durch eine große Menge von Regeln definiert. Die Integration dieser Regeln ermöglicht es den Systemen, welche diese Regeln besitzen, untereinander zu kommunizieren. Die Beschreibungen der Regeln können sich auch voneinander unterscheiden, müssen dann aber kompatibel sein, d.h. zueinander passen (Bsp.: Stecker und Buchse).
Im Unternehmen kommen unterschiedliche Anwendungen zum Einsatz. Es wird mit vielen verschiedenen Firmen, Abteilungen etc. zusammen gearbeitet. Dabei kommen unterschiedliche Anwendungen/ Systeme zum Einsatz. Eine schnelle Arbeitsweise erfordert es, die Daten elektronisch zwischen den Systemen auszutauschen.
Für Schnittstellen sollten die in DIN 44 302 niedergelegten Kurzdefinitionen gelten.

Das Problem

Jedes System speichert die Daten intern in einer speziellen Datenbasis, also in verschiedener Art und Weise, auf die die Verarbeitungsalgorithmen der Programme optimal abgestimmt sind. Die Datenbasen der verschiedenen Systeme unterscheiden sich also vollkommen. Ihr Aufbau und Inhalt hängt auch von den Modellierungs- und Verarbeitungsmöglichkeiten der einzelnen Programme ab. Die externen Dateien, welche gespeichert werden, sind also Auszüge aus der internen Datenbasis. Sie sind schlecht aufeinander abstimmbar, da sie so verschieden sind. Es ist also unmöglich, einen einheitlichen Programmcode für alle Systeme zu nutzen.
Probleme mit Schnittstellen kommen aber nicht nur durch ihre unterschiedliche Datenbasis zustande, sondern häufig auch durch Missverständnisse zwischen der verfügbaren Schnittstellen-Hardware. Die Betriebssysteme unterstützen oft nur unzureichend oder gar nicht die Operationen an den Schnittstellen. Es ist beispielsweise so, dass es bei verschiedenen Betriebssystemen am PC zu unterschiedlichen Definitionen der gleichen Schnittstelle kommen kann. Die PCI- Schnittstelle wird z.B. unter Windows anders definiert, als unter Linux, beschreibt aber das gleiche System.
Dazu kommt eine immer steigende Zahl an Neuentwicklungen und Trends, die neue Möglichkeiten erschließen sollen, aber dadurch auch die Vielfalt vergrößern. Schnittstellen müssen angepasst werden und sich immer dem aktuellen Stand der Technik fügen.
Probleme entstehen aber nicht nur bei dem Datenaustausch zwischen Maschinen, die ihre Inhalte nicht richtig identifizieren und damit lesen können. Es gibt immer Datenverlust. Auch die Kommunikation zwischen Mensch – Maschine ist nur schwer möglich. Um diese Kommunikation zu erleichtern, sollten standardisierte Schnittstellen entwickelt werden.

Der Datenaustausch

Beim Datenaustausch werden ganz allgemein Informationen ausgetauscht. Im einfachsten Fall findet das in Papierform statt. In der Rechnerarchitektur werden Daten zwischen verschiedenen Rechnern ausgetauscht. Dabei gibt es viele Möglichkeiten des Datenaustauschs: Diskette, CD-ROM, Datenträger oder über Netzwerke.
Der elektronische Datenaustausch ist auf zwei Arten von Schnittstellen möglich:

Die Direktschnittstelle

Eine Anwendung kreiert die Daten eines Systems in das Zielsystem. Sie formt die Daten exakt so um, als wären die Daten im Zielsystem selbst entstanden – eine so genannte Direktschnittstelle.

Vorteile:

  • Sollten die Regeln der beiden Systeme (Quelle, Ziel) ähnlich sein, ist ein verlustarmer und sicherer Datenaustausch möglich.

Nachteile:

  • Durch Zuhilfenahme eines Übertragungsprogramms funktioniert nur die Datenübertragung von einem speziellen System in ein spezielles Zielsystem. Also nur in eine Richtung, ohne Austauschmöglichkeit.
  • Gibt es größere Unterschiede zwischen den Systemen, so ist kein reibungsarmer und verlustarmer Datenaustausch möglich.
Direktschnittstelle
Direktschnittstelle

Die neutrale Schnittstelle

Durch die Vereinbarung eines neutralen Formates kann der Austausch durch beliebige Systeme erfolgen. Das bedeutet, das jedes beteiligte System seine Daten in einem neutralen Format schreiben und lesen muss und dann in sein internes Format wandelt.

Vorteile:

  • Jedes beteiligte System kann in jede Richtung Daten austauschen.
  • Neue Software, Applikationen, etc. können relativ leicht in den Datenaustausch eingebunden werden.
  • Das Format ist unabhängig von Neuentwicklungen und Trends, es kann in seiner ursprünglichen Form erhalten bleiben.
    Die beteiligten Systeme müssen sich den aktuellen Neuentwicklungen anpassen, was aber Bestandteil des Systems ist.

Nachteil:

  • Das neutrale Datenformat muss sehr umfassend sein, um alle Anforderungen und Möglichkeiten in jedem System zu realisieren.
Neutrale Schnittstelle
Neutrale Schnittstelle

Lösung:

Mit Hilfe des neutralen Datenformates ist der Austausch durch beliebige Systeme möglich.

Standard
Entwicklung, XML

SOAP – Simple Object Access Protocol

SOAP steht jetzt für SOAP!
Die W3C-Arbeitsgruppe hat entschieden, den Namen SOAP für die Spezifikation V1.2 zu übernehmen. In dieser Version steht SOAP nicht mehr als Akronym für Simple Object Access Protocol, sondern ist eine eigenständige Bezeichnung – also ab jetzt nur noch SOAP.

SOAP – Das Zugriffsprotokoll

SOAP ist ein Protokoll für den Austausch von strukturierten Daten zwischen verteilten Anwendungen. Es ist von großer Bedeutung bei Webanwendungen. Der Datenaustausch erfolgt mittels XML-Dokumenten. Das zu versendende Dokument wird bei SOAP mit einen „Umschlag“ versehen, der die eigentlichen Daten mit den Verwaltungsinforationen anreichert. Nachrichten auf der Basis SOAP können mit jedem herkömmlichen Protokoll der Transport- und Anwendungsschicht (vgl. TCP/IP-Referenzmodell) versendet werden (z.B. http, https, SSL). Die gängigste Kombination ist SOAP über http und TCP. Außerdem kann SOAP in jede Programmiersprache implementiert werden und ist plattformunabhängig. Daraus resultiert die hohe Geschwindigkeit und die breite Akzeptanz. Ursprünglich war SOAP die Abkürzung für Simple Object Access Protocol (Einfaches Objekt-Zugriffs-Protokoll), seit Version 1.2 ist SOAP jedoch offiziell keine Abkürzung mehr, da es nicht (nur) dem Zugriff auf Objekte dient.

Der Aufbau der SOAP-Nachricht

Aufbau einer SOAP-Nachricht
Aufbau einer SOAP-Nachricht

In jeder SOAP-Nachricht ist ein XML-Dokument enthalten, welches einen Umschlag (SOAP Envelope), einen optionalen Kopf (SOAP Header) und einen Datenbereich (SOAP Body) enthält.
Das Envelope umschließt die Nachricht wie ein Umschlag und muss in jeder Nachricht enthalten sein. In diesem Umschlag wird unter anderem angegeben: was in der Nachricht enthalten ist; von wem sie erarbeitet werden soll (URL der Zielapplikation) und welche Angaben der Nachricht optional sind.
Der Header, der Kopf der Nachricht, ist optional und dient für zusätzliche Informationen. Durch ihn kann die Funktionalität der Nachricht erweitert werden, welche im Vorfeld nicht zwischen den Applikationen vereinbart worden ist. Dabei werden bestimmt Attribute definiert.
Der Body, die eigentliche Nachricht, ist dagegen nicht optional und muss in jeder Nachricht vorhanden sein. Er beinhaltet die eigentlichen Informationen, die für den Empfänger gedacht sind. Im Body können beliebig viele Sub-Elemente vorhanden sein, in denen die bestimmten Parameter vorhanden sind.

Standard