In dem Blogbeitrag „CustomApp Teil 1 – Anwendung im Client“ (im Folgenden Teil 1 genannt) wurde bereits beschrieben, was mit einem benutzerdefinierten Menü im Client möglich ist, welche Voraussetzungen notwendig sind und wie mit den einzelnen Menüvarianten gearbeitet werden kann. In dem nun folgenden zweiten Teil soll erläutert werden, was mit der Variante der CustomApp als Webkomponente möglich ist und welche Unterschiede zu der Client-Variante bestehen.

Möglichkeiten und Voraussetzungen

Mit der Webkomponente der CustomApp lässt sich genau wie in der Clientvariante ein zusätzliches Menü in der Weboberfläche von DeltaMaster erstellen, mit welchem Import- und Exportprozeduren auf der relationalen Datenbank mit und ohne Transaktionssteuerung ausgeführt werden können. Damit ist auch schon eine wichtige Voraussetzung für die CustomApp-Webkomponente genannt: ohne installierte WebOption funktioniert sie nicht.
Die erforderlichen Tabellen und Prozeduren, die zusätzlich zu den in Teil 1 beschriebenen Tabellen installiert werden müssen, können durch Ausführen des Skripts „Web_CustomApp.sql“ in der entsprechenden relationalen Datenbank erzeugt werden. Diese Tabellen werden im Gegensatz zur Clientvariante nicht manuell sondern entweder bereits bei der Ausführung des Skripts befüllt oder dienen zur Speicherung interner Werte während einer durch die CustomApp gestarteten Aktion. Die Tabellen, die mit dem Skript „CustomApp.sql“ wie in Teil 1 beschrieben, erzeugt werden, sind ebenfalls erforderlich, benötigen aber zum Teil andere Einträge. Damit wird auch klar, dass zurzeit ein paralleler Betrieb von Client- und Webvariante der CustomApp nicht möglich ist.
Alle erforderlichen Dateien für den Einsatz der CustomApp in DeltaMaster befinden sich im Archiv CustomApp_Web.zip, welches im Blog-Ordner abgelegt ist. Die Dateien funktionieren mit der DeltaMaster WebOption 5.5.8.

Datenbanktabellen

Tabellen

T_SYS_CustomAppMenue
Diese Tabelle wird bereits mit dem SQL-Skript „CustomApp.sql“ angelegt und muss manuell befüllt werden. Da sich die SubTypes im Web von denen im Client unterscheiden, wird diese Tabelle an dieser Stelle noch einmal aufgeführt. Die detaillierte Beschreibung dieser Tabelle und die Beschreibung aller weiteren Tabellen aus diesem SQL-Skript ist Teil 1 zu entnehmen.

Abbildung 1: Tabelle T_SYS_CustomApp_Menue

Mit dem Eintrag in die Spalte Subtype wird der Typ des Menüpunktes bestimmt.
Folgende Subtypes sind möglich:
4 – Asynchroner Aufruf einer Prozedur ohne Parameter, mit Auswahl einer Importdatei, mit Trans-aktion (Manueller Modus = Warten auf Commit oder Cancel)
9 – Asynchroner Aufruf einer Prozedur ohne Parameter, mit Auswahl einer Importdatei, mit Trans-aktion (Manueller Modus = Warten auf Commit oder Cancel); identisch mit SubType = 4
10 – Asynchroner Aufruf einer Prozedur ohne Parameter, mit Auswahl einer Importdatei, mit Transaktion, Autocommit (falls keine Fehler aufgetreten sind, sonst Autocancel)
11 – Asynchroner Aufruf einer Prozedur ohne Parameter, mit Auswahl einer Importdatei, mit Transaktion, Autocommit (immer Commit)
16 – Aufruf einer Prozedur mit Parametern ohne Transaktion z.B. für Datenexport

Folgende Tabellen werden durch das Skript „Web_CustomApp.sql“ angelegt:

T_SYS_ImportStatusDescription

Diese Tabelle enthält die Returncodes für den Status eines Imports.

Abbildung 2: Tabelle T_SYS_ImportStatusDescription

Beispiel:

Die im Beispiel gezeigten Werte werden beim Ausführen des Skripts in die Tabelle eingetragen. Der Importstatus ist abhängig von dem in Tabelle T_SYS_CustomAppMenue gewählten SubType (siehe Absatz 2.1.1.).

T_SYS_ImportTransaction_LOG

Pro Datenimport wird in dieser Tabelle durch die CustomApp ein Eintrag erzeugt, mit welchem dokumentiert wird, wer, wann, welche Datei importiert hat sowie das Ergebnis des Imports durch die Angaben wie viele Datensätze aus der Datei importiert wurden oder nicht (Datensätze mit Fehler). Außerdem wird die StatusID des Imports festgehalten (siehe Einträge in Tabelle T_SYS_ImportStatusDescription in späterem Absatz).

Abbildung 3: Tabelle T_SYS_ImportTransaction_LOG

Beispiel:

Das Beispiel zeigt einen Import der Datei Import_Farben.csv am 10.07.2015 um 11:03 Uhr durch BC\KAUTER. Von den zehn in der Datei enthaltenen Datensätzen konnten acht importiert werden, zwei Datensätze wurden aufgrund von Fehlern nicht importiert. Der Status des Imports = 5 (commit) bedeutet, dass die acht korrekten Datensätze in die Datenbank übernommen wurden. Für den Datenimport wurde der Menüeintrag 1 „Daten importieren“ verwendet, wie in der Tabelle T_SYS_CustomApp_Menue eingetragen.

T_S_User

Die Tabelle T_S_User ist nicht Bestandteil der CustomApp-Tabellen und wird nicht bei Ausführen des Skripts „Web_CustomApp.sql“ erzeugt, da sie oftmals in den meisten Datenbanken zur Identifizierung des angemeldeten Users bereits existiert. Sollte diese Tabelle noch nicht existieren, muss sie angelegt werden. Die Tabelle sollte mindestens zwei Spalten enthalten: UserID als Spalte mit Format Integer und UserName als Spalte vom Format varchar. Die UserID kann frei vergeben werden z. B. als fortlaufende Nummer, in der Spalte UserName muss der Domaine-Username eingetragen werden.

Abbildung 4: Tabelle T_S_User

Die Tabelle kann weitere Spalten zur Identifizierung des Users enthalten, mindestens aber die zwei genannten.

Beispiel:

T_SYS_OpenTransaction_Log

In dieser Tabelle werden alle noch offenen Transaktionen festgehalten, d. h. alle Vorgänge, die noch nicht mit „commit“ oder „cancel“ abgeschlossen wurden.

Abbildung 5: Tabelle T_SYS_OpenTransaction_Log

Die Spalte User_ID enthält die ID des ausführenden Users, wie sie in der Tabelle T_S_User (siehe Absatz 2.1.4) hinterlegt ist.
Als Typ des Datenimports (Spalte Type) sind folgende Einträge durch die CustomApp möglich:

M – manuelle Eingabe

I – Datenimport

Die Tabelle kann auch für Transaktionen über Prozesse im DeltaMaster genutzt werden. Bei Ausführen eines Prozesses, der Daten kopiert oder verschiebt, erfolgen ebenfalls Einträge mit Typ = M in diese Tabelle.

Beispiel:

T_SYS_OpenTransaction_Log_Archive

Wird eine Aktion z. B. ein Datenimport mit „Commit“ oder „Cancel“ abgeschlossen, wird der Eintrag aus der Tabelle T_SYS_OpenTransaction_Log in diese Tabelle verschoben. So werden abgeschlossene Vorgänge archiviert. Ihr Aufbau ist daher mit dem der Tabelle T_SYS_OpenTransaction_Log identisch.

Abbildung 6: Tabelle T_SYS_OpenTransaction_Log_Archive

Sichten

V_SYS_DataEntryMenue

Diese Sicht ist mit der Sicht V_SYS_CustomAppMenue identisch. In der Web-Version der CustomApp wird aber noch die V_SYS_DataEntryMenue zur Steuerung verwendet. Die Sicht wird beim Ausführen des Skipts „Web_CustomApp.sql“ angelegt.

Beispiel für die Sicht:

CREATE VIEW [dbo].[V_SYS_DataEntryMenue] AS

SELECT Menue_ID
      ,Menue_Pos
      ,Menue_EN
      ,Menue_DE
      ,Menue_ES
      ,Menue_FR
      ,Menue_IT
      ,Menue_NL
      ,Menue_PT
      ,Menue_RU
      ,Menue_JP
      ,Menue_KR
      ,Menue_CN
      ,Subtype
      ,Criteria1
      ,Criteria2
      ,Menue_Active
FROM
	dbo.V_SYS_CustomAppMenue

In dem gezeigten Beispiel werden die Menüeinträge und die Berechtigungen wie im Client (siehe Teil 1) übernommen.

Datentypen

TransactionIDTableType

Dieser Datentyp wird über das SQL-Skript „Web_CustomApp.sql“ erzeugt und ist für den Ablauf der CustomApp Web in verschiedenen Prozeduren erforderlich.

Prozeduren

Die Prozeduren, die beim Ausführen des Skripts „Web_CustomApp.sql“ angelegt werden und deren Bezeichnung mit P_SYS beginnt, dürfen nicht verändert werden, alle anderen Prozeduren können für weitere Prüfungen oder Folgeschritte ergänzt werden.

P_DM_EditBegin_Import

Mit dieser Prozedur wird der Import initialisiert. Die Prozedur generiert eine neue TransactionID.

P_DM_EditBegin

Diese Prozedur ist individuell für den Start des Imports zu programmieren. Hier können beispielsweise Berechtigungen geprüft werden und der Eintrag in die Tabelle T_SYS_OpenTransaction_Log erfolgen.

Beispiel:

CREATE PROC [dbo].[P_DM_EditBegin]  @TableName varchar(255),  @TransactionID uniqueidentifier output,
	@ErrorDesc varchar(255) = null Output 
AS
BEGIN
	DECLARE @userid int

	-- Neue TransactionID erzeugen
	SET @TransactionID = newid()

	-- UserID aus T_S_User bestimmen
	SELECT 
		@userID = UserID 
	FROM T_S_User 
	WHERE Username = system_user
		
	-- Transactions Log schreiben
	INSERT INTO T_SYS_OpenTransaction_Log
		(Transaction_ID, [User_ID], TableName, ChangeDate, [Type])
	VALUES
		(@TransactionID, @userid, @TableName, getdate(), 'M')

	RETURN (0)		
	
END

Die Parameter @TransactionID, @TableName werden von der CustomApp beim Aufruf der Proze-dur als Parameter übergeben. Die @userid muss selbst ermittelt werden, z. B. aus der Tabelle T_S_User.

P_SYS_CommitImportLogEntries

Diese Prozedur wird nach Bestätigung des Datenimports durch „Commit“ durch die CustomApp ausgeführt. Mit dieser Prozedur werden die TransactionID und die Prozedur des ausgeführten Da-tenimports ermittelt und an die Prozedur P_DM_EditCommit_Import übergeben.

P_DM_EditCommit_Import

Diese Prozedur wird nach dem Bestätigen des Datenimports durch „Commit“ durch die CustomApp ausgeführt. An dieser Stelle können entsprechende Schritte zur endgültigen Übernahme der importierten Daten in die jeweilige Importtabelle programmiert werden.
Sind beispielsweise verschiedene Importprozeduren für Stamm- oder Bewegungsdaten in der T_SYS_CustomApp_Menue angelegt, kann an dieser Stelle auf verschiedene, individuell zu programmierende Commit-Prozeduren verwiesen werden. Ein Beispiel für eine Commit-Prozedur ist die beschriebene Prozedur P_DM_EditCommit.

P_DM_EditCommit

Mit dieser Prozedur wird der Datenimport bestätigt. Sie wird nicht vom SQL-Skript „Web_CustomApp.sql“ erzeugt, da in ihr individuelle Datenbankaktionen zum Abschluss des Datenimports programmiert werden können. Eine Aktion, die diese Prozedur enthalten sollte, ist das Entfernen der TransactionID und gegebenenfalls das Setzen eines Änderungsdatums (sofern vorhanden und gewünscht) in den importierten Datensätzen der entsprechenden Importtabelle.

Beispiel:

CREATE PROC [dbo].[P_DM_EditCommit]
	@tableName varchar(255),  
	@TransactionID uniqueidentifier ,
	@InputType tinyint = 0,
	@ErrorDesc varchar(255) = null Output 
AS
BEGIN

	DECLARE @sql_log varchar(5000)
	DECLARE @sql varchar(5000)
	DECLARE @tname varchar(255)
	DECLARE @tid varchar(100)
	DECLARE @dt varchar(50)
	
	-- TransactionID in varchar Variable speichern
	SET @tid = @TransactionID
	SET @dt = getdate()

	-- Transaction starten
	BEGIN TRANSACTION

	---------------------------------------------------------------------------
	-- Transaction info löschen, Änderungsdatum setzen
	---------------------------------------------------------------------------
	SET @sql = 'update ' + @tablename + ' set '
	SET @sql = dbo.F_BC_Concat(@sql, 'Transaction_ID = null,', 0, 1)
	SET @sql = dbo.F_BC_Concat(@sql, 'ChangeDate = ''' + @dt + ''',', 0, 1)
	SET @sql = dbo.F_BC_Concat(@sql, 'where	Transaction_ID = ''' + @tid + '''', 0, 1)
	EXEC(@sql)

	---------------------------------------------------------------------------
	-- Datensatz in Tabelle T_SYS_OpenTransaction_Log löschen
	---------------------------------------------------------------------------
	SET @sql = 'delete from T_SYS_OpenTransaction_Log ' 
			+ ' where Transaction_ID = ''' + @tid + ''''
			+ ' and TableName = ''' + @tablename + ''''
	EXEC(@sql)

	-- Transaktion abschliesen
	COMMIT TRANSACTION
	
	RETURN (0)
END

P_SYS_CancelImportLogEntries

Diese Prozedur wird nach Abbruch des Datenimports durch „Cancel“ durch die CustomApp ausge-führt. Mit dieser Prozedur werden die TransactionID und die Prozedur des ausgeführten Datenimports ermittelt und an die Prozedur P_DM_EditCancel_Import übergeben.

P_DM_EditCancel_Import

Diese Prozedur wird nach dem Abbrechen des Datenimports durch „Cancel“ durch die CustomApp ausgeführt. An dieser Stelle können entsprechende Schritte zum endgültigen Abbruch und gegebenenfalls Zurücksetzen von Daten in der jeweiligen Importtabelle programmiert werden.
Sind beispielsweise verschiedene Importprozeduren für Stamm- oder Bewegungsdaten in der T_SYS_CustomApp_Menue angelegt, kann an dieser Stelle auf verschiedene, individuell zu programmierende Cancel-Prozeduren verwiesen werden. Ein Beispiel für eine Cancel-Prozedur ist die beschriebene Prozedur P_DM_EditCancel.

P_DM_EditCancel

Mit dieser Prozedur wird der Datenimport abgebrochen. Sie wird nicht vom SQL-Skript „Web_CustomApp.sql“ erzeugt, da in ihr individuelle Datenbankaktionen zum Abbruch des Datenimports programmiert werden können. Aktionen, die diese Prozedur enthalten sollte, sind das Löschen der importierten Datensätze aus der Importtabelle und das Löschen des Eintrags in die Tabelle T_SYS_OpenTransaction_Log.

Beispiel:

CREATE PROC [dbo].[P_DM_EditCancel]  
	@TableName varchar(255),  
	@TransactionID uniqueidentifier  ,
	@ErrorDesc varchar(255) = null Output 
AS
BEGIN
DECLARE @sql varchar(5000)
	DECLARE @actualtablename varchar(255)
	DECLARE @colname varchar(50)
	DECLARE @s varchar(50)
	DECLARE @tid varchar(100)

	SET @tid = @TransactionID

	BEGIN
		
		SET @actualtablename = 'T_IMPORT_Color'
		
		-- Transaktion starten
		BEGIN TRANSACTION
		------------------------------------------------------------------------------
		-- Datensätze löschen
		------------------------------------------------------------------------------
		SET @sql = 'delete from ' + @actualtablename + ' where TransactionID = ''' + @tid + 
		''''
		EXEC (@sql)
		
		------------------------------------------------------------------------------
		-- TransactionLog löschen
		------------------------------------------------------------------------------
		SET @sql = 'delete from T_SYS_OpenTransaction_Log ' 
				+ ' where Transaction_ID = ''' + @tid + ''''
				+ ' and TableName = ''' + @TableName + ''''
		EXEC(@sql)

		-- Transaktion abschliessen
		COMMIT TRANSACTION

		RETURN(0)
	END
END

P_SYS_SetImportStatus

Diese Prozedur befüllt nach dem Datenimport die Tabelle T_SYS_ImportTransaction_LOG. Dabei werden neben dem Importstatus auch die Anzahl der verarbeiteten, der korrekten und der fehlerhaften Datensätze ermittelt und in die Tabelle T_SYS_ImportTransaction_LOG eingetragen.

P_SYS_UpdateImportStatus

Mit dieser Prozedur wird der Importstatus in der Tabelle T_SYS_ImportTransaction_LOG nach Beendigung des Imports durch „Commit“ oder „Cancel“ aktualisiert.

P_SYS_DeleteImportLogEntries

Mit dieser Prozedur werden Einträge in der Tabelle T_SYS_ImportTransaction_LOG gelöscht. Diese Prozedur wird ausgeführt, wenn eine oder mehrere angezeigte Aktionen mit einem Häkchen markiert und durch Betätigen von „Delete“ gelöscht werden:

Abbildung 7: Aktionen manuell bestätigen, abbrechen oder löschen

Beispiele zu den Menüeinträgen und möglichen Aktionen folgen im dritten Teil der Beschreibung der CustomApp zu einem späteren Zeitpunkt.

Aktivieren der Menüfunktion im WebClient

Für die Verwendung der CustomApp im Zusammenhang mit der WebOption sind die Komponenten CustomApp.aspx, CustomApp.css und CustomApp.js in das Verzeichnis des WebClients zu kopieren, in das Unterverzeichnis \bin des WebClients die Komponenten CustomApp.dll und CustomApp.pdb.
Nun muss noch die Datei web.config aus dem Verzeichnis des WebClients angepasst und um folgende Einträge ergänzt werden:

Nach Starten des Browsers und Aufruf der entsprechenden Seite erscheint das Menü nicht in der jeweiligen Analysesitzung sondern bereits auf der Startseite mit dem in der web.config eingegebenen Namen – in unserem Beispiel mit dem Namen Datenimport.

Abbildung 8: Menüpunkt wird auf der Website angezeigt

Wird dieser Menüpunkt gewählt, erscheint das in der Tabelle T_SYS_CustomApp_Menue eingegebene Menü:

Abbildung 9: Menüansicht

Die detaillierte Beschreibung wie die einzelnen Punkte dieses kleinen Menüs funktionieren, erfolgt in Teil 3 zu einem späteren Zeitpunkt.