SAPALink SDK verwenden

Dieser Artikel erklärt die ersten Schritte um mithilfe des KGS SAPALink SDKs eine eigene Storage-Anbindung herzustellen. 

Instructions

1. Allgemeine Beschreibung
2. SAPALink SDK Herunterladen
3. Beschreibung des ZIP-Containers
4. Java-Implementierung mithilfe von OSGi und dem KGS ContentServer
   1. Methodenrümpfe ausimplementieren
   2. Kompilieren
5. Konfigurieren des KGS Generic Store Providers und Nutzung der eigenen SAPALink.class

Allgemeine Beschreibung

Das KGS SAPALink SDK wurde für Kunden entwickelt, die bereits ein eigenes DMS-Archiv bzw. Storage besitzen und diesen um SAP-Anbindungen erweitern wollen. Dabei gibt es zwei Möglichkeiten: 

• Die SAPALink.dll mithilfe von C++ selbst kompilieren und direkt ansprechen
• mithilfe von JAVA und dem KGS Generic Storage Provider das DMS-Archiv anbinden.

Der Kunde muss lediglich die vorgegebenen Methodenrümpfe ausimplementiern. Dazu gehören Methoden wie LinkOpen zur Verbindungsherstellung zum eigenen Archiv oder alle notwendigen Funktionen für CREATE. Der KGS ContentServer spielt hierbei immer eine zentrale Rolle.

SAP System ↔ KGS ContentServer ↔ (Generic Storage Provider) ↔ SAPALINK-Implementierung ↔ Store/DMS des Kunden

SAPALink SDK Herunterladen

Das KGS SAPALink SDK ist im Downloadbereich https://download.kgs-software.com/ (Version SAPALink_SDK_v210H.zip)zu finden.

Beschreibung des ZIP-Containers

Dieses Zip enhält:

• Docu
  • SAPALink Add-On 2_10A.pdf
  • SAPALink Query.pdf
  • SAPALink SDK ImpRevGuide 210H.pdf
• Runtime
  • SAPALink.DAT
  • SAPALINKTEST.exe
  • Storage-profile.txt
• SAPALINK
  • die C++ Quellen für SAPALink.dll
• SAPALINK.JAVA
  • DMSException.java
  • SAPALink.java
• SAPALINKTEST
  • Quellen (C++) für den SAPALINKTEST.exe
• Testdocuments
  • Einige Testdokumente (tif,pdf)

Beschreibung:

1. Docu:

• Beinhaltet neben der eigentlichen SAPALINK SDK Anleitung auch zwei KGS-spezifische Anleitungungen. SAPALink Add-On 2_1 bezieht sich hierbei auf die erweiterten Fuktion "componentCreateCOLD" sowie die Funktion "DocumentKeysSet".

2. Runtime:

• Der Runtime Ordner behinhaltet ein bereits kompiliertes Programm "SAPALINKTEST.exe", mit welcher sich die Funktionalität einer eigenen Implementierung testen lassen. Wir empfehlen dennoch das KGS API Tester hierfür zu nutzen.
• SAPALink.DAT wird als "Settings-Datei" vom SAPALINKTEST.exe verwendet.
• Storage-profile.txt muss auf eine gültige KGS Storage-Configuration zielen.

3. SAPALINK

• In diesem Ordner liegen die unkompilierten C++-Quellen einer SAPALINK (dll)-Implementierung. Ist es gewünscht eine eigene SAPALINK-Implementierung ohne zuhilfenahme des OSGi-Generic-Store-Bundles (für SAPALINK.JAVA) zu nutzen, so müssen alle Funktionen in diesen Quellen ausimplementiert werden.

4. SAPALINK.JAVA

• Insofern die Klassen in JAVA geschrieben werden, so sind die beiden Dateien (DMSException für Errorhandling sowie SAPALink.java für die zu implementierenden Methoden) auszuimplementieren und mit einem Java-compiler zu kompilieren.

5. SAPALINKTEST

• Um zu sehen, wie der SAPALINKTEST (c++) kompiliert wurde und in die Methoden zu schauen hat die KGS sich entschlossen diesen Quellcode zu Verfügung zu stellen.

6. TestDocuments

• eine handvoll Dateien zum Testen. es kann auch jede andere beliebige Datei genutzt werden.

Java-Implementierung mithilfe von OSGi und dem KGS ContentServer

a.)

Der von KGS bevorzugte Weg den Kunden mit der SAPALink Implementierung zu unterstützen ist der Weg mit Java und dem aktuellen OSGi-Container. Hierzu müssen die Klassen "SAPALink.java" sowie "DMSException.java" aus dem Ordner SAPALINK.JAVA (siehe oben) implementiert werden. In dieser Anleitung wird ein Beispiel zu den (simplen) Methoden "infoGetVendorName()" und "infoGetProductName()" ausimplementiert.

In den Klassen stehen neben den Methodenrümpfen auch als Kommentar die Funktion, den Rückgabewert und ggf. Parameter.

// --------------------------------------------------------------------
	// Function: infoGetVendorName
	//
	// Returns the vendor’s name as a String.
	// Parameters: none
	// Returncode: vendor’s name -->  String
	// --------------------------------------------------------------------
	public String infoGetVendorName() throws DMSException
	{
		String csRet = null;
		return csRet;
	}

Wie zu sehen ist, wird hier der VendorName (Herstellername) des anzubindenen Archives abgefragt. Hier kann der Kunde einen beliebigen Namen zurückgeben. Zb. "Max Mustermann AG".

public String infoGetVendorName() throws DMSException
	{
		return "Max Mustermann AG";
	}

Widmen wir uns nun dem Produktname zu. Auch dieser kann beliebig sein.

// --------------------------------------------------------------------
	// Function: infoGetProductName
	// Returns the name of the product (DMS) as a String.
	// Parameters: none
	// Returncode: product name -->  String
	// --------------------------------------------------------------------
	public String infoGetProductName() throws DMSException
	{
		String csRet = null;
		return csRet;
	}

Ein Beispiel wäre "Magic Archive".

	public String infoGetProductName() throws DMSException
	{
		return "Magic Archive";
	}

Zum Testen sollten auch die Methoden "infoGetProductVersion" sowie "infoGetLinkVersion" ausimplementiert werden.

b) Kompilieren

dies Javaklasse "SAPALink.java" können wir nun mithilfe eines beliebigen Java SDKs kompilieren. Dies ist entweder über eine IDE oder über die CommandLine möglich. Zu verkürzung wird hier über die Windows Command Line gearbeitet (die Befehle sind analog zu Unix).

Das ein Java SDK bereits auf dem System installiert und lauffähig ist wird vorrausgesetzt. Es wird in den Ordner via CommandLine mit der Javaklasse navigiert und mit dem Befehl "javac SAPALink.java" die Klasse(n) kompiliert:

Es sollten nun zwei weitere Dateien in dem Ordner vorhanden sein: SAPALink.class und DMSException.class.

Konfigurieren des KGS Generic Store Providers und Nutzung der eigenen SAPALink.class

Es wird eine standardinstallation des KGS ContentServers (auf OSGi-Basis) vorrausgesetzt. 

Als erstes Navigieren wir per WebGUI in den OSGi-Containers des KGS ContentServers. Von dort aus navigieren wie zu der Konfiguration des Generic Store Services (des Bundles KGS Generic SAPALink Provider).

Hier konfigurieren wir zwei Parameter: Der Implementierungspfad und ein Flag bezüglich der nutzung von einer externen SAPALink Implementierung. Konkret sind das die Parameter: "Implementation Folder" und "Use internal Implementation".

Der Implementation Pfad muss auf den Ordner zeigen, in dem unsere kompilierten Klassen (SAPALink.class und DMSException.class) liegen. "Use internal Implementation" muss auf "false" gestellt werden.

"true" (default) würde immer die KGS Store Implementierung (und somit per Konfiguration aus der Storage.conf) auswählen.

Nun starten wir den Webserver neu.

Nach einem Neustart sollten wir nun in der Oberfläche des KGS ContentServers unsere Änderungen sehen:

dies sollte sich auch in der SAPALink Info (Unter "Main → SAPALink Info" wiederspiegeln):

Auch der ArchiveLink Befehl "serverInfo" sollte uns nun das gewünschte Resultat bereitstellen:

http://localhost:8080/KGSAdmin-CS/contentserver?serverInfo&pVersion=0046&resultAs=ascii

Verwandte Artikel