1

Je sais que je peux enregistrer un nouveau "Service Endpoint" dans MS CRM et l'utiliser pour envoyer des messages à Azure Service Bus, mais ce n'est pas ... vraiment ce que je cherche. La méthode ci-dessus finit par envoyer un RemoteExecutionContext sérialisé.Envoyer des messages personnalisés à Azure Service Bus à partir de MS CRM Plugins (Sandbox)

Dans mon cas, je veux avoir un contrôle total sur ce que les messages de bus de service contiendront. Cela signifie sérialiser mes propres classes. J'ai essayé d'utiliser le nugget WindowsAzure.ServiceBus (et ILmerging la nouvelle DLL), mais cela ne fonctionne que dans un environnement non sandbox (CRM sur site), mais j'aimerais aussi que ma solution fonctionne dans CRM Online . Lorsque vous tentez d'utiliser le même code dans le CRM en ligne, puis essayer de créer un TopicClient jette une erreur:

System.Security.SecurityException: That assembly does not allow partially trusted callers

Est-il possible de contourner le problème ci-dessus?

+1

WindowsAzure.ServiceBus a des sources ouvertes sur GitHub. Y a-t-il une raison particulière pour laquelle vous ne pouvez pas prendre les sources et simplement les compiler avec vos plugins CRM? –

+0

@PawelGradecki Hmm, je peux essayer, mais je doute en quelque sorte que cela résoudra le problème. Cela peut être dû au fait que CRM Sandbox ne fait pas confiance à 'System.Web' (même vous ne pouvez même pas utiliser' UrlEncode', par exemple). BTW: Le problème n'est pas dans la fusion des DLL externes. J'ai utilisé avec succès beaucoup de DLL externes dans mes solutions CRM fonctionnant en mode bac à sable. – Shaamaan

Répondre

0

Pour CRM Online, vous pouvez utiliser la logique de conversion/traitement des messages en dehors de sandbox. Il faudra avoir un calcul externe. Étant donné que vous utilisez déjà CRM en ligne, cela ne devrait pas poser de problème.

Une approche que vous pourriez prendre est de convertir CRM construit RemoteExecutionContext au type que vous voulez. Il y a un sample sur la façon d'intégrer Dynamics 365 avec NServiceBus, qui adopte également cette approche. Le calcul auquel je faisais référence serait l'équivalent du point de terminaison CRMAdapterEndpoint de l'échantillon. Le point de terminaison utilise un objet Mapper pour convertir JSON sérialisé RemoteExecutionContext en types personnalisés, ContactCreate et ContactUpdate. Cela vous permettrait d'atteindre ce que vous voulez.

+0

Bien que techniquement correct, j'essaie de simplifier la solution, pas la rendre plus complexe. :/Le besoin d'avoir le contrôle sur les messages provient exactement de ce fait - Je pourrais utiliser le 'RemoteExecutionContext', mais l'envoi d'une classe de modèle sérialisé semble beaucoup plus facile à utiliser plus tard. – Shaamaan