Discussion :

[slacky]

Bonjour,

Je souhaitais savoir si il étais conseillé de programmer ou pas.

Je m'explique, mon client aimerait des liste en cascade, de ce que j'ai pu lire il faut créer ses webservices et rajouter de l'ajax.

Donc possible apparement car j'ai vue du code.

Maintenant est-il conseillé de faire ça ? sachant que toute programmation en plus risque peut-etre de mettre le cirque dans le reste de l'application non ?

Pour exemple, ils aimeraient que lorsque l'ont rentre le code postal, et bien la liste des ville se mette à jour en fonction.

Voila si vous pouvez m'aiguiller, dois-je répondre à cette demande ou mieux vaut éviter ?

Merci.

[Jhell]

Bonjour,

Il y a deux façons de programmer la CRM :

1- tu respectes que qui est "supporté" par MS ; sont concernés notamment tout ce qui passe par l'appel des WebServices CRM et le JavaScript utilisant le dom crmform. Ca tu peux le proposer au client (tes deux demandes entrent dans ce cadre)

2- la modification interdite : attaque de la base en SQL direct, modification de leur JavaScript ou de leur code serveur. C'est totalement à éviter pour un client, mais j'avoue avoir été obligé de le faire en interne pour éviter d'avoir à redévelopper des pages à cause d'un oubli de fonctionnalité de MS...

[KibitO]

Le web service que tu vas attaquer, c'est toi qui l'a créé ou bien il se trouve sur la toile ?

Sinon, Jhell a répondu à tes question

[slacky]

Merci à vous pour vos réponses, ça aide à ma réflexion .

Donc non je ne compte pas changer quoique se soit dans les base de données du CRM.

Le webservice, je le ferais.

C'étais à savoir si l'ajout de script ne va pas géner la maintenance et le fonctionnement normal du CRM à la longue, je n'ai pas de recule la dessus.

Car comme je disais faire des listes déroulantes en cascade pour le code postal et la ville par exemple, n'a peut être pas grand intérêt si il y a des risques de mal fonctionnement par la suite.

[KibitO]

Tout à fait. JavaScript et Ajax doivent être utilisés avec parcimonie.

Les gadgets aussi ^^ On a vite fait de se perdre (et de perdre les codes) avec trop de choses rajoutées sur les fiches.

Sinon, ce qui pourrait être bien, c'est de renseigner des adresses dans CRM (importer une base des villes et des codes postaux) puis de les appeler en ajax sur le champ voulu. Ce que tu veux en fait. C'est faisable et si c'est bien codé, ça ne plantera pas la fiche.

D'autre part, l'inconvénient est qu'il faut s'assurer que tous les clients qui vont utiliser cette fonctionnalité aient un Internet Explorer configuré pour accéder un tel script.

[Jhell]

Pour ce qui est des listes interdépendantes en JS, c'est ce que j'ai développé pour les adresses avec en cascade le pays, la région, le département, la commune et le fantoir (code national de la rue). De plus, dès qu'un seul des niveaux est renseigné, les niveaux suppérieurs se remplissent tout seuls.
Exemple : le code postal est saisi alors le département, la région, le pays sont renseignés et la commune si elle est unique, sinon la lookup des communes s'ouvre spontanément et pré-filtrée d'après le CP saisi.

Les utilisateurs trouvent cela très agréable et les temps de réponses sont très bons.

Cela fonctionne très bien à travers tous les rollup jusqu'alors mais je suis toujours resté sur la CRM 4.

[slacky]

Ok bon et bien j'essairais peut-être de faire ça quand meme.

Mais comme tu dis c'est du gadget même si on dit "Tout ce qui c'est inutile est indispensable". Ben il s'en passeront peut-être.

Merci pour vos réponses, je vous tiendrais au courant si je le fais et sans doute comment je l'aurais fais.

[tdavin]

Comme le dit très justement Jérôme, si on se limite aux éléments supportés par Microsoft, pas de soucis de portabilité/régression lors de correctifs (Update Rollup) ou de migration (Microsoft Dynamics CRM 2011 )

Pas d'accès direct à la base de données même si certains DBA sont tentés

Pour parler avec Microsoft Dynamics CRM 4.0, les Services Web !

Concernant le développement dans le cadre d'une implémentation de Microsoft Dynamics CRM 4.0, c'est justement un de ses atouts, l'extensibilité.
Cependant, il faut bien prendre en compte le contexte d'utilisation de ces développements (utilisateur, type de client utilisé..). Le mode Outlook déconnecté est souvent oublié.

Concernant enfin ton besoin sur les champs d'adresse, la synchronisation Outlook rentre-t-elle en compte, car Outlook synchronise ses informations sur les champs standards, e.g address1_street1, address1_city, etc... Le cas échéant, il faut prendre en compte la gestion des valeurs de ces champs.