Using SAPALink SDK

You may find information about the first steps necessary to your own storage connection with the help of KGS SAPALink SDKs.

General Description

The KGS SAPALink SDK was developed for customers which already use their own DMS archive / storage and wish to extend it with SAP connection abilities. Two options exist in order to create that kind of connection:

• Compiling SAPALink.dll by using a C++ compiler and calling it directly
• Using JAVA and KGS Generic Storage Provider in order to connect the DMS archive.

You will have to implement the given method bodies.

This includes methods like LinkOpen to open a connection to your own archive or all required functions for CREATE.

KGS ContentServer4Storage plays a central role within this process.

SAP System ↔ KGS ContentServer4Storage ↔ (Generic Storage Provider) ↔ SAPALINK-Implementation ↔ Store/DMS of the customer

Downloading SAPALink SDK

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

Description of the ZIP-Container

The ZIP file contains the following:

• Docu
  • SAPALink Add-On 2_10A.pdf
  • SAPALink Query.pdf
  • SAPALink SDK ImpRevGuide 210H.pdf
• Runtime
  • SAPALink.DAT
  • SAPALINKTEST.exe
  • Storage-profile.txt
• SAPALINK
  • C++ sources for SAPALink.dll
• SAPALINK.JAVA
  • DMSException.java
  • SAPALink.java
• SAPALINKTEST
  • Sources (C++) for SAPALINKTEST.exe
• Testdocuments
  • Some test documents (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 with the help of OSGi as well as 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.

Configuration of KGS Generic Store Providers and usage of 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