Archive

Archive for August, 2012

Implémenter la sécurité COGNOS 10. L’authentification et les droits d’accès

August 20th, 2012 No comments
 
 
Mettre en place la sécurité sur COGNOS 10 n’est pas toujours une mince affaire. Il faut d’abord bien comprendre certains principes de base. Il est également important de distinguer l’utilité de chacune des fonctionnalités principales. Enfin, des conseils pour la configuration sont à connaitre pour éviter de rendre l’implémentation de la sécurité longue et laborieuse.

J’ai donc voulu partagé avec ceux que cela pourrait intéresser, certains points de la sécurité COGNOS 10 qu’il faut bien comprendre et connaître avant de commencer la configuration de la sécurité, les concepts de base que l’on retrouve au niveau de l’authentification et des autorisations, cela sous la forme la plus synthétique et la plus facile à mettre en pratique possible.

 

Authentification

Les espace-noms

La mise en place de la sécurité n’est pas obligatoire dans COGNOS 10. Cela signifie que les accès utilisateurs seront en anonyme et dépendront de la configuration par défaut de l’espace-nom intégré COGNOS 10 pour l’utilisateur Anonyme. L’espace-noms intégré de COGNOS contient les objets comme les utilisateurs, les groupes, les rôles et les sources de données.

En plus de l’espace-noms Cognos, chaque ajout d’un nouveau fournisseur d’authentification est représenté par un nouvel espace-noms. La sécurité COGNOS 10 peut être basée sur un ou plusieurs fournisseurs d’authentification. Plusieurs  sont pris en charge comme par exemple active directory server, LDAP, NTLM, etc. (se reporter à la documentation Cognos).

L’espace-noms COGNOS 10 est essentiel. Il ne peut d’ailleurs pas être supprimé dans COGNOS Configuration à la différence de n’importe quel autre espace-noms lié à un fournisseur d’authentification tiers.

     

Les utilisateurs, groupes et rôles

Clarifions ces différents concepts.

L’utilisateur ne peut pas être créé sur le portail COGNOS 10. Toutes les informations (nom, prénom, adresse électronique, etc.) sur l’utilisateur proviendront toujours d’un fournisseur d’authentification.

A noter: Si vous utiliser le fournisseur COGNOS 7, l’utilisateur doit appartenir à au moins une classe d’acces manager pour pourvoir exister dans COGNOS 10.

     

En ce qui concerne les groupes et les rôles, il y a souvent beaucoup de doutes alors que c’est très simple.

Les groupes et les rôles permettent de créer des ensembles organisés d’utilisateurs qui auront les mêmes caractéristiques dans la sécurité. Toutefois il n’est pas possible de se connecter au portail en utilisant le nom du groupe ou du rôle, mais la sécurité relatif à l’utilisateur identifié sera en fonction du ou des groupes/rôles auxquels il appartient.

Ainsi, le groupe et rôle sont quasi identiques exception fait qu’un rôle ne peut pas appartenir à un groupe alors que l’inverse est possible. Le diagramme suivant illustre cette architecture:

 

      

Notez également les points suivants qui sont importants en fonction de votre fournisseur d’authentification.

Si vous n’utilisez pas le fournisseur COGNOS 7 et que vous souhaitez utiliser des groupes importés de votre fournisseur tiers, il vous faudra rajouter ces groupes de votre fournisseur tiers à un groupe ou un rôle de l’espace-noms cognos au risque que ces groupes ne soient pas reconnus par le portail COGNOS.

Si vous utilisez le fournisseur COGNOS 7, les classes utilisateurs vont apparaitre sous forme de rôle sur le portail COGNOS 10.

Comme un utilisateur peut appartenir à plusieurs groupes et rôles sa sécurité correspondra à la fusion de ses différents droits d’accès.

Au sujet de la suppression/création de groupe ou de rôle, le fait de créer un groupe ou un rôle avec le même nom qu’un ancien groupe ou rôle ne permettra pas de récupérer la sécurité supprimée.

Maintenant nous allons parler des droits d’accès, concept qu’il est important de comprendre pour mettre en place une sécurité COGNOS 10.

       

Droits d’accès

L’avantage et l’inconvénient des droits d’accès est qu’ils peuvent être définis sur presque tout, de l’utilisateur aux pages du portail. Il n’y a pas de préconisation particulière sur le meilleur niveau ou positionner les droits à part celle de faire preuve de bon sens, d’avoir des règles de développement bien définis et de positionner les droits, dans la mesure du possible, sur les niveaux supérieures.

Ci-dessous, le récapitulatif de la documentation Cognos des différents droits d’accès.

 

Les droits dont disposera un utilisateur correspondront à la combinaison des droits définit. Au minimum, un utilisateur doit disposer de droit de passage sur les entrées parent (il s’agit de contenant donc par exemple les dossiers, les packs, les groupes, les rôles, etc.) des entrées auxquelles il veut accéder. Si pour une entrée aucun droit n’est défini, l’entrée héritera des droits de son entrée parent.

Pour chaque droit vous pouvez soit donner ou refuser l’accès mais le refus d’accès prend le pas sur l’octroi. En effet, en cas de conflit entre l’octroi et le refus, l’accès est toujours refusé. Il est donc préférable de ne pas cocher des droits plutôt que de les refuser.

Lorsque vous définirez les droits d’une entrée vous verrez la case à cocher “Remplacer les droits d’accès hérités de l’entrée parent”. Cochée, cette case permet de définir précisément les droits de l’entrée en faisant abstraction des droits de l’entrée parent.

Pour illustrer le fonctionnement des droits d’accès, j’ai créé le tableau suivant qui met en face de certaines opérations les droits d’accès nécessaires.

Ces rappels à l’esprit, vous devriez maintenant pourvoir aborder plus sereinement la mise en place de votre sécurité COGNOS 10.

 

    

LW

Envoyer des IDOC SAP avec BODS

August 7th, 2012 No comments

Retour d’expérience sur le projet GASPAR pour le groupe PVCP (Pierre & Vacances – Center Parcs).

Dans ce projet le challenge était d’utiliser BODS comme middleware pour envoyer à SAP des écritures (pièces) comptables via la technologie IDOC.

Le contexte :

  • Un système Tiers dépose un fichier plat contenant la facturation client et les comptes d’imputations correspondants,
  • BODS charge ce fichier,
  • BODS traduit les imputations comptables du système tiers en code d’imputation comptable SAP,
  • BODS poste la pièce comptable dans SAP au format IDOC en mode message.

Les solutions :

  • Les utilisateurs métier maintiennent dans SAP des tables de correspondance entre compta système tiers et compta de SAP (hors périmètre de ce post),
  • BODS traduit via des lookup_ext les données d’imputation comptables (hors périmètre de ce post),
  • BODS envoi un IDOC par pièce comptable à SAP en utilisant l’IDOC ACC_DOCUMENT003.

La difficulté majeure résidait dans la génération des IDOC. Un fichier plat pouvant contenir jusqu’à 34000 documents comptables générant autant d’IDOC.

Un IDOC SAP ce présente sous un format de type xml. L’ACC_DOCUMENT003 simule la saisie d’une pièce comptable, il y a de nombreux champs à remplir pour satisfaire SAP, et de nombreux contrôles sont réalisés pour que la pièce comptable soit considérée comme juste.

Ce qui nous intéresse ici est la partie génération de l’IDOC.

Génération massive d’IDOC :

1. Structurer les données pour ce rapprocher du schéma cible :

Deux méthodes ont été utilisées sur le projet, création d’une table par segments d’IDOC, ou division de la table source en autant de query que de segments d’IDOC

Chaque IDOC est référencé par un Identifiant unique, un IDOC peut contenir plusieurs lignes, qui doivent être référencées de manière unique par IDOC.

La table/query d’en-tête ne doit comporter qu’une seule ligne par identifiant d’IDOC, les autres tables/query peuvent contenir plusieurs lignes.

A l’image d’un modèle en étoile les données sont réparties entre : la table d’en-tête (Fait) et les tables de lignes (Dimension).

ci-dessous des données en exemple :

2. Lier les Tables/Query à une en-tête pour générer tous les IDOC en une passe. 

(Dans l’exemple précédent : la query “QRY_MATCH_IDOC”)

La query en amont de l’IDOC (query_2) place les segments dans l’IDOC.

Chaque Tables sources doivent être insérées dans la cible comme schéma.

2.1 L’en-tête :

La clause FROM est déterminante pour structurer l’IDOC. La clause FROM de query_2 aura pour valeur la table d’en-tête.

Puis tous les segments d’en-tête auront comme valeur dans la clause FROM le “Row_Generation”. Cela permet de ne remplir l’en-tête qu’une seule fois. Dans l’exemple ci-dessus les segments EDI_DC40, E1BPACHE09 et E1BPACEXTC

(détail d’un segment)

2.2 Les lignes :

Les autres segments sont rempli par les tables correspondantes, avec en clause FROM la table, et en clause WHERE le lien vers l’identifiant de l’en-tête

En exemple le segment E1BPACGL09 :

2.3 Cas particulier d’une duplication de segment :

Dans certains cas un segment doit être répété. Lors de la première itération le segment est paramétré à l’identique des autres, et la deuxième itération la clause FROM prendra pour valeur un “ROW_GENERATION”.

 

3. Paramétrage de l’envoi d’IDOC

Afin d’optimiser l’envoi des IDOC en mode message la fenêtre suivant permet de modifier le nombre d’envoi simultané d’IDOC. Deux solutions, par paquet ou par division chronologique.

La solution d’envoyé les IDOC par paquet de 100 a été choisi compte tenu du paramétrage de SAP chez le client.

Conclusion

Cette méthode permet d’envoyer en masse en quelques minutes des milliers d’IDOC.

Certes BODS est détourné de son utilisation première (ETL) pour devenir un modeste intégrateur, néanmoins les performances sont très bonne.

Aujourd’hui la moyenne est : 1 min / 1000 IDOC de type ACC_DOCUMENT003.

Trucs et astuces sur SSRS

August 1st, 2012 No comments

Bonjour,

Voici quelques petits trucs et astuces utilisés sur SSRS.

Certaines fonctionnalités ne sont disponibles qu’avec la version 2008 R2 de SQL.

Pour commencer, une fonction très utile, qui permet de récupérer les valeurs d’une source de données dans un tableau / graphique basé sur une autre source de données.

fonction Lookup(source_expression, destination_expression, result_expression, dataset)

Exemple :

on récupère dans une 1ère source le pays et le nombre d’habitants (dataset1) et dans une 2ème le pays et le revenu extérieur (dataset2).
Imaginons que nous ayons une matrice avec en ligne la liste des pays. Si on désire par exemple avoir pour chaque pays le rapport revenu par rapport au nombre d’habitant, alors on pourra faire ceci (dans la zone des données de la matrice, on suppose que celle-ci est basée sur le dataset2) :   = Fields!RevExt.value / Lookup(Fields!Country.value, Fields!Country.value, Fields!NbHab.value,”dataset1″)

la fonction lookup va donc regarder le champ Country du dataset en cours, et le comparer au champ Country du dataset défini dans la fonction (3ème paramètre, “dataset1″ dans notre cas), et va récupérer la valeur du champ NbHab dudit dataset.

Si cette fonctionnalité peut paraître simpliste, elle est très utile dans des cas de rapports un peu complexe ou l’on joue sur de nombreuses sources de données.

Dans le cas où l’on trouve plusieurs valeurs pour une même champ de recherche (par exemple, on veut trouver les couleurs disponibles pour une type de produit, on devra utiliser la fonction LookupSet(source_expression, destination_expression, result_expression, dataset) :

=Split(LookupSet(Fields!Product.value, Fields!Product.value, Fields!Color.value,”dataset1″),”,”). Le résultat renvoyé étant un objet, on doit utiliser conjointement la fonction Split, qui “explose” le résultat, en le séparant par une valeur (la “,” dans notre cas)

Enfin, si on souhaite renvoyer une somme de valeur au lieu d’une concaténation de chaine, il faudra créer une fonction qui calcule cette somme. Pour cela, faites un clique droit sur le fond du rapport (pas de la page), et aller dans les propriétés. Dans la section Code, rajouter ce code :

Function SumLookup(ByVal items As Object()) As Decimal
 If items Is Nothing Then
 Return Nothing
 End If
 Dim suma As Decimal = New Decimal()
 Dim ct as Integer = New Integer()
 suma = 0
 ct = 0
 For Each item As Object In items
 suma += Convert.ToDecimal(item)
 ct += 1
 Next
 If (ct = 0) Then return 0 else return suma / ct
 End Function

Pour l’utiliser, il suffit d’écrire dans la section expression : =Code.SumLookup(LookupSet(Fields!Product.value, Fields!Product.value, Fields!Amount.value,”dataset1″))

pour chaque produit du dataset A, on aura donc la somme des ventes réalisées dans le dataset B

 – Utilisation d’un champ du rapport pour éviter des calculs inutiles.

Parfois, on nous demande de calculer des sommes, puis des quantités, et un ratio somme sur quantité. Si cette dernière n’est pas calculé dans le dataset, on a parfois tendance à réutiliser le calcul du champ Somme et le diviser par celui du champ Quantité. Le problème est que dans ce cas, les calculs sont répétés plusieurs fois, et si jamais on a besoin de modifier l’un ou l’autre des champs, on doit également modifier le champ Ratio.

Pour éviter cela, et alléger ainsi le rapport, on peut utiliser les expressions de champs : soit le champ Somme (expr : = Fields!Amount.value*Fields!TxChange.value) et le champ Quantite (expr : =Fields!Quantity.value). Pour calculer le ratio, on utilisera cette expression :   =reportitems!Somme.value / reportitems.Quantite.value

Ainsi, si jamais on doit changer la valeur de l’expression Somme ou Quantité, la valeur du champ Ratio sera automatiquement mise à jour. A noter que reportitems! se rapporte au nom du champ donné.

– Formatage de valeur.

Lorsque l’on a besoin de formater des valeurs de manière simple, on peut utiliser les différents expressions :

N0 : numérique sans décimale (suivant les paramètres régionaux de la machine : ex:  5 200)
N2 : numérique avec 2 décimales (suivant les paramètres régionaux de la machine : ex:  5 200,35)
Nx : numérique avec x décimales (suivant les paramètres régionaux de la machine : ex:  5 200,xxxxx)
P0: pourcentage sans décimale (ex : 15 %)
P2: pourcentage avec 2 décimales (ex : 15,52 %)
Px: pourcentage avec x décimales (ex : 15,xxx %)