Comment faire pour obtenir l'identité de l'utilisateur qui a exécuté un rapport?

Lors de l'exécution d'un rapport dans MSCRM 2011, vous avez deux options pour les sources de données : SQL ou Chercher.

Dans SSRS les journaux d'exécution, l'utilisateur qui a exécuté le rapport est toujours le compte de service.

Lors de l'utilisation de récupérer, dans le rapport du journal de l'exécution, il y a un paramètre CRM_FullName contenant le nom complet de l'utilisateur qui a exécuté le rapport.

Lors de l'utilisation de SQL à la source, il n'y a pas de CRM_FullName paramètre. Comment puis-je savoir qui a couru le rapport? Il doit y avoir un moyen de savoir, depuis les vues Filtrées savoir qui je suis.

InformationsquelleAutor Dominic Goulet | 2012-04-26
  1. 6

    Il n'ya vraiment pas moyen de trouver cette information. Lorsque vous créez un rapport pour MSCRM, vous utilisez un connecteur appelé "MSCRM Connecteur de Données". Ceci peut être vu dans la AdditionnalInfo colonne de la ExecutionLogs3 vue sur la SSR instance. Lors de l'utilisation de ce connecteur et en essayant de montrer un rapport, il vous sera demandé un nom d'utilisateur et mot de passe. C'est là que les choses deviennent intéressantes.

    Le rapport n'est pas fait attendre un nom d'utilisateur/mot de passe! En fait, il s'attend à recevoir les systemuserid (guid) comme nom d'utilisateur et le organizationid (guid) comme mot de passe. Ensuite, il recherche dans la base de données MSCRM_CONFIG pour l'organisation paramètres de base de données. Ensuite, il va dans l'organisation de la base de données et il suffit de faire une set context_info SYSTEMUSERID. Enfin, la filteredviews sont l'appel d'une fonction nommée " [dbo].[fn_FindUserGuid] " qui récupère le context_info. C'est la façon dont les vues filtrées sont en bon état de marche, tout en étant connecté sous le compte de service.

    Que vous avez prévu, nous ne pouvons pas savoir à l'utilisateur qui a exécuté le rapport car le nom d'utilisateur et mots de passe dans les SSR sont jamais connecté n'importe où (pour des questions de sécurité, peut-être).

    La meilleure option que j'ai trouvé pour le journal qui a couru un rapport est en fait de créer une procédure stockée qui va faire une instruction select sur les vues filtrées (ou toutes les tables, comme il est), puis ouvrez une session dans une table distincte de la déclaration, les paramètres de la procédure et de la context_info(). Puis, dans SSRS j'ai appeler cette fonction au lieu d'aller à l'vues filtrées directement.

    InformationsquelleAutor Dominic Goulet
  2. 5

    Répondre modifié pour inclure l'obtention de l'utilisateur fullname si sql source est utilisée.

    1. Enregistrer un paramètre, UserID, avec la valeur par défaut comme

      =Utilisateur!UserID

    2. Utiliser la requête suivante dans votre jeu de données

      SÉLECTIONNEZ DomainName, FullName

      DE SystemUserBase

      OÙ (DomainName = @UserID)

    3. Ensuite utiliser

      =Champs!FullName.Valeur

    dans votre rapport.

    Dans le CRM les données utilisateur sont stockées dans le SystemUserBase table, et le Nom de la colonne est le de Domaine\nom d'utilisateur stockées dans de l'Utilisateur!Nom d'utilisateur du rapport.
    Si vous préférez l'utilisation de points de vue, l'utilisation FilteredSystemUser vue au lieu de SystemUserBase table.

    Pour fetchxml essayez les solutions suivantes:
    L'opérateur opérateur='eq-userid' signifie l'égalité d'accès à l'utilisateur actuel.

    <fetch version='1.0' output-format='xml-platform' mapping='logical' distinct='true'>
<entity name='team'>
<attribute name='name' />
<attribute name='businessunitid' />
<attribute name='teamid' />
<order attribute='name' descending='false' />
<link-entity name='teammembership' from='teamid' to='teamid' visible='false' intersect='true'>
<link-entity name='systemuser' from='systemuserid' to='systemuserid' alias='user'>
    <attribute name='fullname' />
    <attribute name='systemuserid'/>
        <filter type='and'>
        <condition attribute='systemuserid' operator='eq-userid' />
        </filter>
</link-entity>
</link-entity>
</entity>
</fetch>

    Ensuite, dans votre rapport, vous pouvez utiliser le code suivant dans une expression pour obtenir les utilisateurs fullname

    =Premier(Champs!user_fullname.Valeur, "GetUserData")

    où le jeu de données est appelé GetUserData

    • La question était sur l'utilisation de SQL à la Source. Comme indiqué dans la question, je sais qu'il est enregistré lors de l'utilisation de FetchXML.
    • Oui vous avez raison, j'ai édité la réponse à inclure l'extraction du nom d'utilisateur si sql source a été utilisée.
    • Votre réponse (à l'aide de l'Utilisateur!UserID) affiche le nom d'utilisateur dans le rapport, mais il ne sera pas enregistrée dans les journaux d'exécution. Ma question à l'origine demandé comment faire pour récupérer cette info dans le journal de l'exécution. Merci bien pour le temps investi.
    InformationsquelleAutor Bojan Borisovski
  3. 0

    Sera le nom d'utilisateur suffit-il? c'est à dire vous pouvez utiliser quelque chose comme
    ="Generated by " & User!UserID ?

    InformationsquelleAutor Nathan Griffiths