Le connecteur K2 pour SQL Server

Cet article fait partie d’une série d’articles détaillés sur les connecteurs K2. Vous pouvez retrouver des liens vers les autres articles en fin de billet.

Parmi les connecteurs standards K2, on retrouve le connecteur (dans le vocabulaire K2, on parlera de service broker K2) pour bases de données SQL Server, un grand classique, et surement l’un des connecteurs les plus utilisés.

Logo SQL Server

Ce connecteur est un connecteur dynamique, au même titre que les connecteurs Web Services ou SharePoint par exemple, c’est-à-dire que lors de son instanciation, K2 va aller découvrir le contenu de la base à connecter et créer les méthodes d’accès associées aux objets existants ; lorsqu’une mise à jour de structure de la base est réalisée, il faudra aller rafraîchir l’instance du service broker K2 afin d’y faire refléter les modifications.

NB : A contrario d’un connecteur statique qui expose automatiquement un nombre déterminé de méthodes (par exemple : le connecteur Active Directory ou encore Exchange) et qui ne nécessite donc pas de rafraîchissement.

Nous allons donc faire un petit tour d’horizon des fonctionnalités attachées à ce connecteur et aborder les éléments de configuration, mais voyons dans un 1er temps quel peut-être son usage.

Usage

Le service broker SQL Server a principalement 2 usages :

  1. Permettre d’utiliser, dans ses applications K2, des données provenant de bases de données SQL Server déjà existantes. Bases que l’on appelle souvent “bases de référentiel” ou “bases métier”.
  2. Servir pour créer un espace de stockage pour persister les données utilisées dans les applications K2 en dehors de la base de données K2. On parlera également de “bases métier”, mais cette fois-ci la base est créée spécifiquement pour le besoin. Sur une production, ce cas d’utilisation est préféré à l’utilisation des smartobjects de type smartbox, car cela offre un plus large éventail de fonctionnalités.

Configuration

Pour la configuration, utilisons la base de données exemple fournie avec SQL Server (dans mon cas, la version 2012 de la base AdventureWorks) ainsi que l’outil K2 smartobject service tester (disponible dans le répertoire bin du répertoire d’installation de K2).

Une fois l’outil lancé, déroulez le menu ServiceObject Explorer, puis faîtes un clic-droit sur l’entrée SQL Server Service et choisissez Register ServiceInstance :

Configuration d'une instance SQL Server

Les paramètres disponibles :

  1. Authentication Mode : permet de choisir le compte qui se connectera à SQL Server lors de l’utilisation du connecteur (il faut alors choisir entre impersonation, compte de service K2, Single Sign-On, Static ou OAuth), en fonction du choix, les paramètres suivant devront/pourront être renseignés. Ce paramètre est lié aux permissions qui devront être accordées aux utilisateurs sur la base de données à connecter.
  2. On Different SQL Server : à positionner à true si la base de données à laquelle on souhaite se connecter est sur un serveur SQL différent de celui qui héberge la base de données K2.
  3. Non-Word character replacement for object system names : choix du caractère qui sera utilisé pour les “propriétés K2” si certains objets SQL (colonne, table etc.) utilisent des caractères spéciaux.
  4. Command Timeout : gestion de la durée pour le timeout concernant les requêtes.
  5. Database Maximum Decimal Value : la valeur par défaut couvre une bonne partie des cas, vous pouvez cependant la modifier si votre base le nécessite.
  6. Database : le nom de la base à connecter, incluant le nom d’instance s’il y a plusieurs instances sur le serveur.
  7. Server : le nom du serveur SQL.
  8. Use parameters for stored procedures : cela permet d’éviter un problème qu’il y avait sur des versions précédentes de K2 qui faisait que chaque paramètre d’entrée d’une procédure stockée était obligatoire pour K2 (alors que dans les faits ils ne l’étaient pas forcément).
  9. Use native SQL Execution : à true, les requêtes passent directement en SQL plutôt que par un dataset intermédiaire, c’est plus performant, mais cela nécessite que la base soit sur le même serveur SQL que la base K2.
  10. Encrypt connection : permet le chiffrement SSL sur les appels SQL (ou sur les flux autres que HTTP). Cela nécessite une configuration au préalable côté SQL Server (un certificat doit être installé et configuré).

 

Exemples de configuration de l’instance du service broker :

Hypothèses exemple 1 :

  • la base se nomme AdventureWorks2012,
  • elle est sur le même serveur que la base de données K2.

Configuration correspondante :

  • Authentication Mode : Impersonate (valeur par défaut mais le choix est dépendant de votre besoin).
  • On Different SQL Server : false (valeur par défaut).
  • Non-Word character replacement for object system names : _ (valeur par défaut mais le choix est dépendant de votre besoin).
  • Command Timeout : 30 (valeur par défaut mais le choix est dépendant de votre besoin).
  • Database Maximum Decimal Value : 23,9 (valeur par défaut mais pas de modification nécessaire pour cette base de données).
  • DatabaseAdventureWorks2012.
  • Server : LOCALHOST (valeur par défaut).
  • Use parameters for stored procedures : true (valeur par défaut).
  • Use native SQL Execution : true (valeur par défaut).
  • Encrypt connection : false (valeur par défaut).

Hypothèses exemple 2 :

  • la base se nomme TestBase,
  • elle est sur un SQL Server Azure,
  • la chaîne de connexion standard à la base est Server=tcp:x4xxx9x53x.database.windows.net,1433;Database=TestBase;User ID=K2@x4xxx9x53x;Password=MyPassword;Trusted_Connection=False;Encrypt=True;Connection Timeout=30;. Cette chaîne est récupérable sur votre Windows Azure Management Dashboard, au niveau des SQL Databases.

Configuration correspondante :

  • Authentication ModeStatic.
    • UserName : K2@x4xxx9x53x.
    • Password : MyPassword.
  • On Different SQL Servertrue.
  • Non-Word character replacement for object system names : _ (valeur par défaut mais le choix est dépendant de votre besoin).
  • Command Timeout : 30.
  • Database Maximum Decimal Value : 23,9 (valeur par défaut).
  • Database : TestBase.
  • Server : tcp:x4xxx9x53x.database.windows.net,1433.
  • Use parameters for stored procedures : true (valeur par défaut).
  • Use native SQL Execution : false.
  • Encrypt connection : false.

 

Fonctionnalités

Comme indiqué précédemment, le connecteur étant dynamique, lors de son instanciation (phase de configuration) K2 va parcourir l’ensemble des objets de types Table, Vue et Procédure Stockée et exposer les méthodes d’accès à ces objets :

  1. Table :
      1. les méthodes CRUD sont exposées dès lors que la table dispose d’une clé primaire.
      2. la méthode List est toujours exposée et des filtres peuvent être mis en place en s’appuyant sur chacune des propriétés.

    Table

  2. Vue :
      1. la méthode List est exposée et des filtres peuvent être mis en place en s’appuyant sur chacune des propriétés.

    View

  3. Procédure Stockée :
      1. la méthode List est exposée lorsque la procédure retourne des données, et des filtres peuvent être mis en place en s’appuyant sur chacune des propriétés.
      2. la méthode Execute est exposée lorsque la procédure ne retourne pas de données.

    Stored Procedure

Une fois instancié, vous pouvez créer les smartobjects correspondant aux objets qui vous intéressent et utiliser le smartobject event lorsque vous êtes dans la modélisation d’un processus ou l’action de règle Execute a SmartObject method dans la configuration d’un formulaire. Dans le cas où vous souhaiteriez accéder à ces objets par du développement, vous pouvez y accéder via les API.net, les services WCF ou les services REST de K2.

Utiliser un smartobject SQL dans un process
Utiliser un smartobject SQL dans un formulaire

Compatibilité

Officiellement, le service broker SQL Server de K2 fonctionne avec toutes les versions de SQL Server supérieures à SQL Server 2008 SP3 (en tout cas, à ce jour – février 2016 – et pour la version courante de K2 – 4.6.11). Pour des informations plus détaillées/récentes sur la compatibilité, il faut se référer à la matrice de compatibilité.

N’hésitez pas à utiliser les commentaires si vous avez des questions.

Happy K2ing!

Autres billets de la série sur les connecteurs :

jean

Directeur technique de K2 France depuis 2006 et passionné par les technologies, je travaille dans le monde du BPM et des applications métier depuis… que je travaille :). Vous pouvez également me suivre sur twitter, linkedin.

6 thoughts to “Le connecteur K2 pour SQL Server”

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *