Fichiers de configuration des passerelles de données

Cette section est générée automatiquement par Blue Prism en fonction des réglages de la base de données Blue Prism. Elle détermine comment les événements sont entrés dans le moteur de passerelles de données pour traitement. Dans l'exemple ci-dessous, ils sont récupérés du tableau BPADataPipelineInput dans la base de données Blue Prism.

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* * * * *"

}

}

Si nécessaire, les zones suivantes de l'entrée peuvent être modifiées en fonction des préférences requises.

 

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

Cela détermine la fréquence à laquelle la requête SQL est exécutée pour demander les données du tableau BPADataPipelineInput. La valeur par défaut de toutes les trois secondes peut être mise à jour en remplaçant 3 par la valeur requise.

 

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

C'est l'instruction SQL exécutée sur la base de données Blue Prism pour isoler les événements du tableau BPADataPipelineInput. La valeur contrôle le nombre maximum de lignes tirées du tableau BPADatapipelineInput à chaque intervalle. La valeur par défaut de 3000 peut être modifiée, si nécessaire.

Les sorties déterminent où les événements sont envoyés. Si les sorties ont été configurées à l'aide de l'assistant des passerelles de données, elles seront incluses ici. Tout événement traité sera envoyé à toutes les sorties listées dans la configuration.

output {

file {

path => "C:\data.txt"

}

 

csv {

path => "C:\data.csv"

}

}

Dans l'exemple ci-dessus, un fichier .txt et une sortie .csv sont spécifiés. Chaque événement envoyé au système de passerelles de données sera écrit dans un fichier texte sur C:\data.txt et aussi un fichier csv sur C:\data.csv

Pour une liste des sorties disponibles, consultez cette page : https://www.elastic.co/guide/en/logstash/current/output-plugins.html

Cette section détaille la structure des événements dans Logstash après qu'ils ont été reçus de Blue Prism. Ces informations peuvent être utilisées pour construire des instructions conditionnelles dans la configuration Logstash afin de dériver les événements vers les sorties en fonction de leur contenu et de créer des formats de message personnalisés pour vos sorties.

L'événement (soit un log de session ou un tableau de bord publié) est stocké dans la base de données Blue Prism en tant que chaîne de caractères JSON. Afin de convertir cette chaîne de caractères JSON en un ensemble de champs qui peuvent être utilisés dans Logstash, le filtre JSON est ajouté à la configuration :

filter{

json{source => "eventdata"

target => "event"}

}

Cela ajoute le log de session / le tableau de bord publié sous forme de champs imbriqués dans le champ « event » (événement).

Par exemple :

[event][eventType] contient le type d'événement (log de session, tableau de bord publié ou données d'objet personnalisées).

[event][EventData] contient les données de l'événement sous forme de champs imbriqués.

[event][EventData][SessionNumber] contient le numéro de session, si c'est un événement du log de session.

Pour envoyer seulement des journaux de session d'un processus nommé « ProcessA » vers un fichier texte, vous pouvez utiliser une instruction conditionnelle autour de votre sortie :

output{

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

file {

path => “C:\log.txt”

}

}

}

Pour une liste complète des champs disponibles, consultez les tableaux suivants.

Général

Événement	Description
[event][eventType]	Le numéro qui représente le type d'événement : 1 = Log de session 2 = Tableau de bord publié 3 = Personnalisé 4 = Analyse de file d'attente de travail
[event][EventData]	Les données de l'événement. La structure de ces données variera selon le type d'événement.

Type d'événement – Logs de session

Événement	Description
[event][EventData][StartDate]	La date de début de l'étape du processus formatée en notation ISO 8601. Par exemple : "2019-02-11T07:59:54.829674+00:00"
[event][EventData][SessionNumber]	Le numéro de session pour la session à laquelle appartient le log de session.
[event][EventData][ResultType]	Le type de résultat de l'étape du processus.
[event][EventData][Result]	Le résultat de l'étape du processus.
[event][EventData][AttributeXML]	Les paramètres d'entrée et de sortie de l'étape sérialisés en XML.
[event][EventData][ProcessName]	Le nom du processus auquel appartient cette étape. Ce sera vide si le log de session est enregistré à partir d'un objet métier.
[event][EventData][ObjectName]	Le nom de l'objet métier auquel appartient cette étape. Ce sera vide si le log de session est enregistré à partir d'un processus.
[event][EventData][ActionName]	Si ce log provient d'une étape d'action, c'est le nom de l'action. Autrement, il sera vide.
[event][EventData][PageName]	Le nom de la page à laquelle appartient cette étape qui a créé ce log de session.
[event][EventData][StageType]	Le type d'étape qui a créé ce log de session.
[event][EventData][StageId]	L'identifiant de l'étape qui a créé ce log de session.

Type d'événement – Tableaux de bord publiés

Événement	Description
[event][EventData][Source]	Le nom du tableau de bord publié.
[event][EventData][Subject]	Le nom de la dalle du tableau de bord qui a généré les données.
[event][EventData][Values]	Les données de la dalle du tableau de bord.

Type d'événement – Données objet personnalisées

Événement	Description
[event][EventData][CustomDataCollection]	Les données personnalisées du processus qui seront envoyées.
[event][EventData][SessionNumber]	Le numéro de session du processus d'où viennent les données.
[event][EventData][StageID]	L'identifiant de l'étape d'où cette action est appelée.
[event][EventData][StageName]	Nom de l'étape de l'action Envoyer des données personnalisées.
[event][EventData][StageType]	Le type de l'étape de l'action Envoyer des données personnalisées.
[event][EventData][StartDate]	La date de démarrage de la session sur laquelle est exécutée l'action Envoyer des données personnalisées.
[event][EventData][ProcessName]	Le nom du processus d'où l'action est appelée.
[event][EventData][PageName]	Le nom de la page du processus sur lequel se trouve l'action de personnalisation des données.
[event][EventData][ObjectName]	L'objet d'où proviennent les données –sera toujours « Passerelles de données ».
[event][EventData][actionName]	L'action dont les données proviennent – sera toujours « Envoyer des données personnalisées ».

Lorsque des journaux de session et des données de tableau de bord sont envoyés vers des fichiers texte séparés, des instructions conditionnelles peuvent être appliquées aux sorties qui ne passeront des événements à une sortie seulement s'ils remplissent une ou plusieurs conditions parmi ces conditions. Cela permet à des sorties, personnalisées dans l'éditeur avancé ou créées dans un éditeur de texte externe, de prendre en charge des fonctionnalités Logstash qui ne sont pas fournies dans l'assistant de configuration de passerelles de données. Par exemple, des sorties peuvent être modifiées pour seulement envoyer des données pour des processus spécifiés ou des dalles de tableau de bord.

Dans cet exemple, les instructions conditionnelles s'agissant des sorties de fichiers vérifient une certaine valeur EventType. Le type d'événement des logs de session est de 1 et celui des tableaux de bord est de 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}"}

}

}

}

Pour plus d'informations sur la structure des événements tirés de la base de données Blue Prism, consultez Structure d'événement.

Les sorties de base de données, configurées dans l'assistant, doivent respecter un format attendu :

• Il doit y avoir une colonne eventType de type entier : cela enregistre le type d'événement.
• Il doit y avoir une colonne eventData de type nvarchar(max) : cela enregistre les événements sérialisés dans une chaîne de caractères JSON.

Dans les configurations avancées, les colonnes du tableau et les données insérées dans le tableau peuvent être personnalisées.

Dans cet exemple, certains champs des événements du log de session sont envoyés au tableau tableabc dans une base de données.

La sortie de la base de données jdbc insère le numéro de session, le nom du processus et les champs attributexml du log de session dans les colonnes correspondantes du tableau tableabc.

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]"]

}

}

}

Pour une liste complète de tous les événements et plus d'informations sur la structure d'événement, consultez Structure d'événement.

Filtrer les événements et les sorties dérivées en utilisant des instructions conditionnelles

Dans cet exemple, le champ [event][EventType] est utilisé pour envoyer des types d'événements à des fichiers séparés en fonction du type d'événement : un log de session (EventType == 1) ou un tableau de bord publié (EventType == 2).

Le type d'événement pour des données d'objets personnalisés (EventType == 3) n'est pas précisé et donc aucune donnée de ce type dans le moteur des passerelles de données ne sera incluse dans la liste des données ignorées.

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}"}

}

}

}

Envoyer des événements en fonction des noms de processus de log de session

Dans cet exemple, des événements pour une sortie particulière basée sur un nom de processus issu d'un log de session. Il y a deux sorties :

• Tous les événements obtenus sont envoyés au fichier texte C:\allevents.txt
• Tous les événements du log de session du processus Process123 sont également envoyés au point de terminaison HTTP indiqué.

input {

jdbc {

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

jdbc_connection_string => "jdbc:sqlserver://localhost:1433;databaseName=ExampleDB;"

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

jdbc_user => "<%SQL Serv.username%>"

jdbc_password => "<%SQL Serv.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 {

file {

path => "c:\allevents.txt"

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

}

}

if [event][EventType] == 1 and [event][EventData][ProcessName] == "Process123" {

bphttp {

url => "localhost:8080/api/post"

http_method => "post"

headers => {"Authorization" => "Basic <base64><%SQL Serv.username%>:<%SQL Serv.password%></base64>"}

}

}

}

Lorsque des identifiants ou d'autres données sensibles sont requis dans la configuration, ils devraient être ajoutés à un identifiant Blue Prism, puis référencés dans la configuration par le nom d'identifiant.

Lorsqu'un identifiant Blue Prism est créé pour une utilisation dans les configurations des passerelles de données, le type d'identifiant doit être Identifiant de passerelle de données. Ces identifiants sont accessibles uniquement par le système de passerelle de données et ne sont pas accessibles aux processus Blue Prism.

Les identifiants peuvent être référencés dans la configuration en utilisant la syntaxe <%{credentialname}.{property}%>, où {credentialname} est le nom de l'identifiant et {property} est le nom de la propriété dans l'identifiant.

Par exemple, pour utiliser le nom d'utilisateur d'un identifiant nommé cred1, le code de configuration serait respectivement <%cred1.username%> et <%cred1.password%>.

Les propriétés d'identifiant personnalisées peuvent être consultées en utilisant le nom de propriété.