- Avant de commencer
- Démarrage
- Intégrations
- Travailler avec des applications de processus
- Travailler avec des tableaux de bord et des graphiques
- Travailler avec des graphiques de processus
- Travailler avec des modèles de processus Découvrir et importer des modèles BPMN
- Afficher ou masquer le menu
- Informations contextuelles
- Exporter (Export)
- Filtres
- Envoi d’idées d’automatisation au Automation Hub d’UiPath®
- Balises
- Dates d’échéance
- Comparer
- Vérification de la conformité
- Analyse des causes profondes
- Simulation du potentiel d’automatisation
- Déclenchement d'une automatisation à partir d'une application de processus
- Afficher les données de processus
- Création d'applications
- Chargement des données
- Personnaliser les applications de processus
- Introduction aux tableaux de bord
- Travailler avec l'éditeur de tableau de bord
- Créer des tableaux de bord
- Tableaux de bord
- Gestionnaire de l’automatisation
- Définition de nouvelles tables d'entrée
- Ajout de champs
- Ajouter des tables
- Configuration requise pour le modèle de données
- Affichage et modification du modèle de données
- Exportation et importation de transformations
- Afficher le journal des transformations
- Modification et test des transformations de données
- Structure des transformations
- Conseils pour l'écriture de SQL
- Fusion des journaux d'événements
- Gestionnaire de processus
- Publication des tableaux de bord
- Modèles d'applications
- Ressources supplémentaires
- Balises et dates d'échéance prêtes à l'emploi
- Modification des transformations de données dans un environnement local
- Setting up a local test environment
- Métriques de temps de traitement personnalisées
- Différences de SQL entre Snowflake et SQL Server
- Configuration settings for loading input data
- Création d'un journal d'événements
- DataBridgeAgent
- Configuration système requise
- Configurer DataBridgeAgent
- Ajouter un connecteur personnalisé à DataBridgeAgent
- Utiliser DataBridgeAgent avec le connecteur SAP pour l'accélérateur de découverte Purchase-to-Pay
- Utiliser DataBridgeAgent avec le connecteur SAP pour l'accélérateur de découverte Order-to-Cash
- Extension de l’outil d’extraction SAP Ariba
- Caractéristiques de performances
- Comment annuler une exécution de données à partir de la base de données
- Comment ajouter une règle de table d'adresse IP pour utiliser le port SQL Server 1433
- Lors de la création d'une application de processus, le statut reste dans Créer une application (Creating app)
- Configuration de Dapr avec Redis en mode cluster
- Transformations de données
- Charger des données
- Synchronisation des données C
Guide de l'utilisateur de Process Mining
SQL Server Vs. Snowflake
Dans un environnement de développement local, les transformations s'exécutent sur SQL Server, tandis que Snowflake est utilisé avec Process Mining Automation Suite. Bien que la plupart des instructions SQL fonctionnent à la fois sur SQL Server et Snowflake, il peut exister de légères différences dans la syntaxe, ce qui est susceptible d'entraîner des différences de résultats renvoyés.
Pour écrire des instructions SQL qui fonctionnent sur les deux systèmes de base de données :
- Écrivez les noms de champ entre guillemets doubles, par exemple
Table."Field". - Empêcher l'utilisation de fonctions SQL différentes dans Snowflake et SQL Server, par exemple
string_agg()etlistagg().
Le package pm_utils est livré avec un ensemble de fonctions qui fonctionnent sur les deux types de bases de données, reportez-vous à Bases de données multiples. Par exemple, au lieu d'utiliser string_agg() ou listagg(), le pm_utils.string_agg() entraînera le même comportement pour les deux bases de données. Si pm_utils ne contient pas la fonction souhaitée, une instruction jinja doit être créée pour s'assurer que la bonne fonction est appelée sur chaque base de données.
Concaténation de string
Pour combiner en chaînes, utilisez la fonction pm_utils.concat() . Cela produira les mêmes résultats pour SQL Server et Snowflake.
Exemple : pm_utils.concat("This is a nice string", null) = "This is a nice string" La concaténation de chaînes ne doit pas être effectuée avec des opérateurs tels que + ou || , car ils sont différents pour les deux bases de données (Snowflake utilise || et SQL Server utilise + ). De plus, la fonction standard concat() a un comportement différent sur les deux systèmes :
| SQL Server | Snowflake |
|---|---|
null seront ignorées et traitées comme une chaîne vide. | null font que le résultat entier sera null. |
Tri
Le tri est géré différemment dans Snowflake et dans SQL Server.
Exemple : ... order by "Attribute_1" desc, "Attribute_2" ...
Valeurs nulles
| SQL Server | Snowflake |
|---|---|
null sera trié par défaut en premier (croissant) | null sera trié par défaut en dernier (croissant) |
Gérer les majuscules
| SQL Server | Snowflake |
|---|---|
| les majuscules sont triées comme prévu (AaBbCc) | trie d'abord par majuscules, puis par lettres non majuscules (ABCabc) |
En tirets
Exemple : -Accountant-
| SQL Server | Snowflake |
|---|---|
| les tirets sont ignorés dans le tri (de sorte que « -Accountant- » soit traité de la même manière que « Accountant ») | les tirets seront triés en haut |
Gestion des espaces
Lorsque vous effectuez un regroupement par valeurs « A » et « A », cela est considéré comme une seule valeur dans SQL Server, mais comme deux valeurs différentes dans Snowflake. Par conséquent, le rognage est conseillé si vos données peuvent causer ce problème.
Sensible à la casse
Par défaut, SQL Server ne respecte pas la casse tandis que Snowflake est sensible à la casse. Cela signifie que Table."Field" = "Some_value" et Table."Field" = "SOME_VALUE" renverront le même ensemble de résultats dans SQL Server, mais potentiellement deux ensembles de résultats différents dans Snowflake.
Il est conseillé de modifier le comportement de votre base de données SQL Server locale pour qu'il corresponde au comportement de Snowflakes, afin d'éviter tout problème. Cela peut être accompli en définissant le classement de la base de données sur une valeur sensible à la casse.