Daten-Gateways – Konfigurationsdateien

Dieser Abschnitt wird automatisch von Blue Prism auf Grundlage der Blue Prism Datenbankeinstellungen erzeugt. Er legt fest, wie Ereignisse zur Verarbeitung in die Daten-Gateways-Engine gezogen werden. Im nachfolgenden Beispiel werden sie von der Tabelle „BPADataPipelineInput“ in die Blue Prism Datenbank aufgenommen.

input {

jdbc {

jdbc_driver_library => "..\sqljdbc_4.2\enu\jre8\sqljdbc42.jar"

jdbc_connection_string => "jdbc:sqlserver://SQL_SERVER_INSTANCE:1433;databaseName=BP_DATABASE;"

jdbc_driver_class => "com.microsoft.sqlserver.jdbc.SQLServerDriver"

jdbc_user => "<%Data Gateways BP Database SQL User.username%>"

jdbc_password => "<%Data Gateways BP Database SQL User.password%>"

statement => "delete top(3000)from BPADataPipelineInput with (rowlock, readpast) output deleted.eventdata"

schedule => "*/3* * * * *"

}

}

Bei Bedarf können die folgenden Bereiche des Inputs an die Anforderungen angepasst werden.

 

`schedule => "*/3* * * * *"`

Damit wird festgelegt, wie oft die SQL-Abfrage ausgeführt wird, die Daten von der Tabelle „BPADataPipelineInput“ anfragt. Der Standardwert des Drei-Sekunden-Takts kann verändert werden, indem 3 durch den gewünschten Wert ersetzt wird.

 

`statement => "delete top(3000)from BPADataPipelineInput with (rowlock, readpast) output deleted.eventdata"`

Diese SQL-Anweisung wird mit der Blue Prism Datenbank ausgeführt, um Ereignisse aus der Tabelle „BPADataPipelineInput“ abzurufen. Der Wert regelt die maximale Anzahl von Zeilen, die in jedem Intervall von der Tabelle „BPADatapipelineInput“ abgerufen werden. Der Standardwert 3000 kann bei Bedarf geändert werden.

Filter können zur zwischenzeitlichen Verarbeitung eines Ereignisses verwendet werden. Das können Aktionen wie das Hinzufügen, Entfernen oder Bearbeiten bestimmter Felder eines Ereignisses sein, bevor sie zu den Outputs gesendet werden, z. B. das Entfernen des Felds „AttributeXML“ eines Sitzungslogs.

Eine Liste aller verfügbaren Filter-Plug-ins finden Sie hier: https://www.elastic.co/guide/en/logstash/current/filter-plugins.html

Standardmäßig enthält die von Blue Prism erzeugte Konfiguration einen einzigen Filter:

filter{

json {

source => "eventdata"

target => "event"

}

}

Konfigurationen enthalten standardmäßig einen einzigen Filter für JSON, der zum Parsen und Erweitern der JSON Zeichenfolge verwendet wird, die die konfigurierten Datentypen enthält (Sitzungslogs, Dashboards usw.), damit die Inhalte in der Konfigurationsdatei aufgerufen werden können.

Dieser Abschnitt kann bearbeitet werden, um Filter hinzuzufügen oder zu entfernen, aber der standardmäßige JSON Filter sollte nicht entfernt oder verändert werden.

Outputs legen fest, wohin Ereignisse gesendet werden. Wenn Outputs mit dem Daten-Gateways-Assistenten konfiguriert wurden, werden sie hier hinzugefügt. Jedes verarbeitete Ereignis wird an jeden in der Konfiguration gelisteten Output gesendet.

output {

file {

path => "C:\data.txt"

}

 

csv {

path => "C:\data.csv"

}

}

Im obigen Beispiel werden eine .txt-Datei und ein .csv-Output spezifiziert. Jedes an das Daten-Gateway-System gesendete Ereignis wird in eine Textdatei unter C:\data.txt und auch eine CSV Datei unter C:\data.csv geschrieben

Eine Liste der verfügbaren Outputs finden Sie hier: https://www.elastic.co/guide/en/logstash/current/output-plugins.html

In diesem Abschnitt wird die Struktur der Ereignisse in Logstash beschrieben, nachdem sie von Blue Prism empfangen wurden. Mit diesen Informationen können Sie Bedingungsanweisungen in der Logstash-Konfiguration erstellen, um Ereignisse je nach Inhalt an Outputs umzuleiten oder benutzerdefinierte Nachrichtenformate für Ihre Outputs zu erstellen.

Das Ereignis (entweder Sitzungslog oder veröffentlichtes Dashboard) wird in der Blue Prism Datenbank als JSON Zeichenfolge gespeichert. Um diese JSON Zeichenfolge in einen Feldsatz umzuwandeln, der in Logstash verwendet werden kann, wird der JSON Filter zur Konfiguration hinzugefügt:

filter{

json{source => "eventdata"

target => "event"}

}

Dadurch wird das Sitzungslog/veröffentlichte Dashboard in Form von verschachtelten Feldern unter dem Feld „event“ hinzugefügt.

Zum Beispiel:

[event][eventType] enthält den Ereignistyp (Sitzungslog, veröffentlichtes Dashboard oder benutzerdefinierte Objektdaten).

[event][EventData] enthält die Daten für das Ereignis in Form von geschachtelten Feldern.

[event][EventData][SessionNumber] enthält die Sitzungsnummer, wenn es sich um ein Sitzungslog-Ereignis handelt.

Um nur Sitzungslogs von einem Prozess namens „ProcessA“ an eine Textdatei zu senden, können Sie eine Bedingungsanweisung für Ihren Output verwenden:

output{

If [event][eventType] == 1 and [event][EventData][ProcessName] == “ProcessA” {

file {

path => “C:\log.txt”

}

}

}

In den folgenden Tabellen finden Sie eine vollständige Auflistung der verfügbaren Felder.

Allgemein

Ereignis	Beschreibung
[event][eventType]	Diese Zahl steht für den Ereignistyp: 1 = Sitzungslog 2 = Veröffentlichtes Dashboard 3 = Benutzerdefiniert 4 = Arbeitswarteschlangen-Analyse
[event][EventData]	Die Daten für das Ereignis. Die Struktur dieser Daten variiert je nach Ereignistyp.

Ereignistyp – Sitzungslogs

Ereignis	Beschreibung
[event][EventData][StartDate]	Das Startdatum der Prozessphase, formatiert gemäß ISO 8601. Zum Beispiel: „2019-02-11T07:59:54.829674+00:00“
[event][EventData][SessionNumber]	Die Sitzungsnummer der Sitzung, zu der dieses Sitzungslog gehört.
[event][EventData][ResultType]	Der Ergebnistyp der Prozessphase.
[event][EventData][Result]	Das Ergebnis der Prozessphase.
[event][EventData][AttributeXML]	Die Input- und Output-Parameter der in XML serialisierten Phase.
[event][EventData][ProcessName]	Der Name des Prozesses, dem diese Phase angehört. Dieses Feld bleibt leer, wenn das Sitzungslog von einem Geschäftsobjekt erfasst wird.
[event][EventData][ObjectName]	Der Name des Geschäftsobjekts, dem diese Phase angehört. Dieses Feld bleibt leer, wenn das Sitzungslog von einem Prozess erfasst wird.
[event][EventData][ActionName]	Wenn dieses Log aus einer Aktionsphase stammt, ist dies der Name der Aktion. Andernfalls bleibt dieses Feld leer.
[event][EventData][PageName]	Der Name der Seite, dem die Phase angehört, die dieses Sitzungslog erstellt hat.
[event][EventData][StageType]	Der Typ der Phase, die dieses Sitzungslog erstellt hat.
[event][EventData][StageId]	Die ID der Phase, die dieses Sitzungslog erstellt hat.

Ereignistyp – veröffentlichte Dashboards

Ereignis	Beschreibung
[event][EventData][Source]	Der Name des veröffentlichten Dashboards.
[event][EventData][Subject]	Der Name der Dashboard-Kachel, die die Daten erzeugt hat.
[event][EventData][Values]	Die Daten aus der Dashboard-Kachel.

Ereignistyp – benutzerdefinierte Objektdaten

Ereignis	Beschreibung
[event][EventData][CustomDataCollection]	Die benutzerdefinierten Daten des Prozesses, die gesendet werden.
[event][EventData][SessionNumber]	Die Sitzungsnummer des Prozesses, von dem die Daten stammen.
[event][EventData][StageID]	Die ID der Phase, von der diese Aktion abgerufen wird.
[event][EventData][StageName]	Der Name der Aktionsphase „Benutzerdefinierte Daten senden“.
[event][EventData][StageType]	Der Typ der Aktionsphase „Benutzerdefinierte Daten senden“.
[event][EventData][StartDate]	Das Startdatum der Sitzung, in der die Aktion „Benutzerdefinierte Daten senden“ ausgeführt wird.
[event][EventData][ProcessName]	Der Name des Prozesses, von dem die Aktion abgerufen wird.
[event][EventData][PageName]	Der Name der Prozess-Seite, auf der sich die Aktion mit den benutzerdefinierten Daten befindet.
[event][EventData][ObjectName]	Das Objekt, von dem die Daten stammen – immer „Daten-Gateways“.
[event][EventData][actionName]	Die Aktion, von der die Daten stammen – immer „Benutzerdefinierte Daten senden“.

Wenn Sitzungslogs und Dashboard-Daten an separate Textdateien gesendet werden, können Bedingungsanweisungen auf die Outputs angewandt werden, damit die Ereignisse nur bei Erfüllung einer oder mehrerer Bedingungen an einen Output übergeben werden. Dadurch können Outputs, die individuell im erweiterten Editor oder in einem externen Texteditor erstellt wurden, Logstash-Funktionen unterstützen, die beim Daten-Gateways-Konfigurations-Assistenten nicht verfügbar sind. Zum Beispiel können Outputs bearbeitet werden, sodass sie Daten nur an bestimmte Prozesse oder Dashboard-Kacheln senden.

In diesem Beispiel überprüfen die Bedingungsanweisungen die Datei-Outputs auf einen bestimmten EventType-Wert. Sitzungslogs haben den Ereignistyp 1, Dashboards haben den Ereignistyp 2.

input {

jdbc {

jdbc_driver_library => "..\sqljdbc_4.2\enu\jre8\sqljdbc42.jar"

jdbc_connection_string => "jdbc:sqlserver://localhost\sqlexpress:1433;databaseName=a;"

jdbc_driver_class => "com.microsoft.sqlserver.jdbc.SQLServerDriver"

jdbc_user => "<%Data Gateways BP Database SQL User.username%>"

jdbc_password => "<%Data Gateways BP Database SQL User.password%>"

statement => "delete top(3000)from BPADataPipelineInput with (rowlock, readpast) output deleted.eventdata"

schedule => "*/3 * * * * *"

}

}

filter {

json {

source => "eventdata"

target => "event"

}

}

output {

if [event][EventType] == 2 and [event][EventData][Source] == "Dashboard 1" {

file {

path => "C:\dashboardlogs.txt"

codec => line { format => "%{event}"}

}

}

if [event][EventType] == 1 {

file {

path => "C:\sessionlogs.txt"

codec => line { format => "%{event}"}

}

}

}

Weitere Informationen zur Struktur der Ereignisse, die von der Blue Prism Datenbank abgerufen werden, erhalten Sie unter Ereignisstruktur.

Im Assistenten konfigurierte Datenbank-Outputs müssen ein erwartetes Format einhalten:

• Es muss eine Spalte „eventType“ des Typs „integer“ geben – dort wird der Ereignistyp gespeichert.
• Es muss eine Spalte „eventData“ des Typs „nvarchar(max)“ geben – dort werden die Ereignisse seriell in einer JSON Zeichenfolge gespeichert.

Bei erweiterten Konfigurationen können die Tabellenspalten und die in die Tabelle eingegebenen Daten individuell angepasst werden.

In diesem Beispiel werden bestimmte Felder der Sitzungslog-Ereignisse an die Tabelle „tableabc“ in einer Datenbank gesendet.

Der Datenbank-Output „jdbc“ fügt die Felder „sessionnumber“, „processname“ und „attributexml“ aus dem Sitzungslog in die passenden Spalten der Tabelle „tableabc“ ein.

input {

jdbc {

jdbc_driver_library => "..\sqljdbc_4.2\enu\jre8\sqljdbc42.jar"

jdbc_connection_string => "jdbc:sqlserver://localhost\sqlexpress:1433;databaseName=a;"

jdbc_driver_class => "com.microsoft.sqlserver.jdbc.SQLServerDriver"

jdbc_user => "<%Data Gateways BP Database SQL User.username%>"

jdbc_password => "<%Data Gateways BP Database SQL User.password%>"

statement => "delete top(3000)from BPADataPipelineInput with (rowlock, readpast) output deleted.eventdata"

schedule => "*/3 * * * * *"

}

}

filter {

json {

source => "eventdata"

target => "event"

}

}

output {

if [event][EventType] == 1 {

bpjdbc {

connection_string => "jdbc:sqlserver://TheServer;databaseName=MyDB;integratedSecurity=true;"

driver_jar_path => "..\sqljdbc_4.2\enu\jre8\sqljdbc42.jar"

driver_class => "com.microsoft.sqlserver.jdbc.SQLServerDriver"

statement => ["insert into tableabc(EventType, EventData) values(?, ?)", "[event][EventType]", "[event][EventData]"]

}

}

}

Eine vollständige Liste aller Ereignisse und zusätzliche Informationen zur Ereignisstruktur finden Sie unter Ereignisstruktur.

Mit Bedingungsanweisungen Ereignisse filtern und Outputs umlenken

In diesem Beispiel wird das Feld „[event][EventType]“ verwendet, um Ereignistypen an unterschiedliche Dateien zu senden, je nachdem, ob es sich beim Ereignistyp um ein Sitzungslog (EventType == 1) oder ein veröffentlichtes Dashboard (EventType == 2) handelt.

Der Ereignistyp für benutzerdefinierte Objektdaten (EventType == 3) ist nicht angegeben, deshalb werden Daten dieses Typs nicht in die Daten-Gateways-Engine aufgenommen, sondern verworfen.

input {

jdbc {

jdbc_driver_library => "..\sqljdbc_4.2\enu\jre8\sqljdbc42.jar"

jdbc_connection_string => "jdbc:sqlserver://localhost\sqlexpress:1433;databaseName=a;"

jdbc_driver_class => "com.microsoft.sqlserver.jdbc.SQLServerDriver"

jdbc_user => "<%Data Gateways BP Database SQL User.username%>"

jdbc_password => "<%Data Gateways BP Database SQL User.password%>"

statement => "delete top(3000)from BPADataPipelineInput with (rowlock, readpast) output deleted.eventdata"

schedule => "*/3 * * * * *"

}

}

filter {

json {

source => "eventdata"

target => "event"

}

}

output {

if [event][EventType] == 2 and [event][EventData][Source] == "Dashboard 1" {

file {

path => "C:\dashboardlogs.txt"

codec => line { format => "%{event}"}

}

}

if [event][EventType] == 1 {

file {

path => "C:\sessionlogs.txt"

codec => line { format => "%{event}"}

}

}

}

Ereignisse auf Grundlage von Sitzungslog-Prozessnamen senden

In diesem Beispiel werden Ereignisse auf Grundlage eines Prozessnamens aus einem Sitzungslog an einen bestimmten Output gesendet. Es gibt zwei Outputs:

• Alle Ereignisse werden an die Textdatei „C:\allevents.txt“ gesendet
• Sitzungslog-Ereignisse aus dem Prozess Process123 werden zudem an den angegebenen HTTP-Endpunkt gesendet.

input {

jdbc {

jdbc_driver_library => "..\sqljdbc_4.2\enu\jre8\sqljdbc42.jar"

jdbc_connection_string => "jdbc:sqlserver://localhost\sqlexpress:1433;databaseName=a;"

jdbc_driver_class => "com.microsoft.sqlserver.jdbc.SQLServerDriver"

jdbc_user => "<%Data Gateways BP Database SQL User.username%>"

jdbc_password => "<%Data Gateways BP Database SQL User.password%>"

statement => "delete top(3000)from BPADataPipelineInput with (rowlock, readpast) output deleted.eventdata"

schedule => "*/3 * * * * *"

}

}

filter {

json {

source => "eventdata"

target => "event"

}

}

Wenn Anmeldedaten oder andere vertrauliche Daten in der Konfiguration erforderlich sind, sollten sie zu Blue Prism Anmeldedaten hinzugefügt und dann in der Konfiguration durch den Anmeldedatennamen referenziert werden.

Wenn Sie Blue Prism Anmeldedaten zur Verwendung in Daten-Gateways-Konfigurationen erstellen, muss der Anmeldedatentyp Daten-Gateway-Anmeldedaten sein. Diese Anmeldedaten können nur vom Daten-Gateway-System und nicht von Blue Prism Prozessen aufgerufen werden.

Anmeldedaten können in der Konfiguration mit der Syntax <%{credentialname}.{property}%> referenziert werden, wobei {credentialname} der Name der Anmeldedaten und {property} der Name der Anmeldedateneigenschaft ist.

Beispiel: Für den Benutzernamen der Anmeldedaten cred1 wäre der Konfigurationscode <%cred1.username%> bzw. <%cred1.password%>.

Benutzerdefinierte Anmeldedateneigenschaften können mit dem Eigenschaftsnamen aufgerufen werden.