(...) Die Besonderheit des Business Document Service besteht (...) darin, dass er aus Sicht einer ihn verwendenden Anwendung völlig in sich abgeschlossen ist und nur über die Zugriffsklassen cl_bds_document_set und document_proxy angesprochen wird.¹ Wenngleich also die inneren Vorgänge des Business Document Service sehr komplex sein mögen, ist weder seine interne Implementierung noch sein Customizing von Belang für die Kundenakte, da diese keine Auswirkungen auf seine programmatische Bedienung haben.

Dabei werden diverse Aufgabenfelder durch ihn abgedeckt. Zum einen stellt er eine zentrale Verwaltung aller betriebswirtschaftlichen Dokumente dar, ohne dass diese in der operativen Datenbank des SAP-Systems enthalten sein müssen. Viel mehr erfolgt die physische Dokumentablage mit dem ArchiveLink, welcher neben der SAP-Datenbank auch auf externe Content Server und Archivsysteme zugreifen kann. Zum anderen bietet er die Möglichkeit, von allen Dokumenten mehrere, konkurierende Versionen und Varianten zu verwalten. Und letztlich stellt er eine Verknüpfung her zwischen den Dokumenten und den betriebswirtschaftlichen Objekten, zu welchen die Dokumente gehören.

Vor SAP-Release 4.7 bezog sich diese Verknüpfung immer auf ein Business Objekt, seit Release 4.7 können jedoch auch ABAP-Klassen herangezogen werden. In Folge dessen werden exakt drei Werte benötigt, um eine gültige Verknüpfung herstellen zu können:

• Der Objekttyp gibt an, ob sich die Verknüpfung auf ein Business Objekt, eine ABAP- Klasse oder auf ein nicht spezifiziertes Objekt bezieht.

• Der Objektname gibt den Namen des Business Objekt oder der ABAP-Klasse an.

• Der Objektschlüssel stellt eine einheitliche Kennnummer dar, welche die Objektinstanz eindeutig kennzeichnet.

Für die Kundenakte bietet sich hier an, die Mutterklasse aller Einträge als Verknüpfungsziel anzugeben, wobei der Objektschlüssel in diesem Falle die in der Kundenakte verwendete Kennnummer des Eintrags sein sollte. Dementsprechend muss die Kundenakte keinen Gebrauch von der Versionsverwaltung des Business Document Service machen, weil aufgrund der geforderten Vollständigkeit der Einträge und dem Schutz vor Verfälschungen keine Eintragsversionen verwaltet werden. Neue Versionen eines Sachverhalts sollten immer zu einem neuen Eintrag mit eigener Kennnummer führen.

Eine Eigenheit des Business Document Service besteht in der Verwendung von sogenannten Komponenten und Signaturen. Als Komponenten werden dabei alle Teile eines Dokuments bezeichnet, da der Business Document Service die Verwaltung von mehrteiligen Dokumenten unterstützt. Mithin besteht jedes Dokument aus mindestens einer Komponente, wobei zu jeder Komponente ein Satz von Signaturen gehört, welche die Komponente näher beschreiben. In diesem Sinne sind die Signaturen vergleichbar mit den angeregten Metamerkmalen der Kundenakte und auch ihre Funktionsweise gestaltet sich analog.

Tabelle 1: Signaturen zur Beschreibung von Komponenten

Dabei wird anhand der Signaturen eine weitere Besonderheit des Business Document Service evident, welche von der Kundenakte berücksichtigt werden muss: Die Unterscheidung zwischen der technischen Beschreibung eines Dokuments und seiner fachlichen Bedeutung. Laut [WOLF07] (S. 408-410) stellt dies ein zweistufiges Definitionskonzept dar, wobei die technische Beschreibung allein auf den MIME-Type² des Dokuments abzielt. Die Dokumentart hingegen ist an den technischen Dokumenttyp gebunden, beschreibt diesen aber aus betriebswirtschaftlicher Sicht. Leider ist die Beziehung zwischen dem Dokumenttyp und der Dokumentart eine 1:n-Beziehung, so dass hinter einer Dokumentart nicht mehrere technische Typen stehen können, womit die Definition einer einheitlichen Dokumentart für die Einträge der Kundenakte verhindert wird. Da das Standard-Customizing des ArchiveLink allerdings viele Standardarten für die gängigen Office- und Dokumentdateien kennt, kann auf diese bedenkenlos zurückgegriffen werden.

Quellenangaben

WOLF07: Frank Wolf (2007), ABAP Objects, 1. Auflage, dpunkt.verlag GmbH, Heidelberg