Fonctions generiques de creation d'acteur
Les fonctions génériques de création d'acteurs sont là pour permettre au développeur la création d'écran en gardant les mêmes services qu'a créé une personne, un client, une entreprise, une association ou tous autres acteurs qui reposent sur les tables Party d'ofbiz.
Deux services sont disponibles :
* genericCreateParty : création d'un acteur * createTwoPartiesAndRelation : création de deux acteurs et de leur relation
GenericCreateParty
Cette fonction a pour object de créer un acteur et les principales informations nécessaires : son ou ses rôles, ses coordonnées et son utilisateur de connexion.
Le service appelé se nomme genericCreateParty, il est défini dans le fichier : applications/party/servicedef/nservices.xml Actuellement, les entrées possibles du service sont :
- Les champs de la table Person : informations d'une personne
- Les champs de la table Company: informations d'une entreprise
- Les champs de la table PartyGroup : informations d'un groupement d'acteur
- Les champs de la table PostalAddress : informations de l'adresse postale principale
- Les champs de la table UserLogin : informations d'une personne
- groupRoleTypeId : identifiant d'un type de rôle avec des rôles fils (roleTypeRollup)
- workContact : numéro de téléphone du travail de l'acteur
- faxContact : numéro de fax de l'acteur
- mobileContact : numéro du téléphone mobile de l'acteur
- email : courriel de l'acteur
- postalContactMechPurposeTypeIds : liste des types d'adresse à appliquer à l'adresse postale principale (adresse de facturation, adresse d'expédition, ...)
- partyId : identifiant de l'acteur dans Neogia
- Les champs de la table PostalAddress avec en prefix pa_0_2_ : informations de l'adresse postale secondaire
- postalContactMechPurposeTypeIds avec en prefix pa_0_2_ : liste des types d'adresse à appliquer à l'adresse postale secondaire
- Les champs de la table PostalAddress avec en prefix pa_0_3_ : informations concernant une troisième adresse postale
- postalContactMechPurposeTypeIds avec en prefix pa_0_3_ : liste des types d'adresse à appliquer à cette troisième adresse postale
Si le type d'acteur n'est pas renseigné dans le contexte du service, ce dernier essayera de le déterminer en fonction des valeurs présentes.
Concernant l'entrée postalContactMechPurposeTypeIds, pour pouvoir indiquer les différents types d'adresse, la forme devra contenir les champs avec comme suffix _o_pa_cpt. Pour les types d'adresse concernant la deuxième et troisième adresse, la forme devra contenir les champs avec comme suffix _o_cpt pour les champs avec un préfixe respectif à leur adresse.
Ex : <input name="address1" type="text" /> <input name="contactPurposeBill_o_pa_cpt" type="hidden" value="BILLING_LOCATION" /> <input name="pa_o_2_address1" type="text" /> <input name="pa_o_2_contactPurposeShip_o_cpt" type="hidden" value="SHIPPING_LOCATION" />
En entrée de service, postalContactMechPurposeTypeIds aura un élément {BILLING_LOCATION}, et la seconde adresse aura un postalContactMechPurposeTypeIds avec aussi un élément {SHIPPING_LOCATION} A savoir : l'adresse principale reçoit toujours le type GENERAL_LOCATION.
CreateTwoPartiesAndRelation
Ce service a pour but de créer deux acteurs et de les associer entre eux par une relation. Si un seul acteur est présent, il se contentera de créer l'acteur. En fait, ce service appelle genericCreateParty pour la création des acteurs.
Le service appelé se nomme createTwoPartiesAndRelation, il est défini dans le fichier : applications/party/servicedef/nservices.xml Actuellement, les entrées possibles du service sont :
- les champs de la table PartyRelationship
- firstParty map contenant les informations du premier acteur
- secondParty map contenant les informations du second acteur
Pour construire les maps des acteurs, il faut préfixer les informations qui leurs sont relatives par :
* o_1_ pour le premier * o_2_ pour le deuxième
Les champs que peuvent contenir ces map sont les champs disponibles en entrée du service genericCreateParty
Etendue possible
Il est sûrement possible d'étendre les services pour qu'ils supportent plus d'informations de manière générique, mais il faut veiller à la complexité et l'utilité des améliorations car le code doit rester simple et souple à travailler.
Dans les travaux à effectuer, le service de mise à jour générique d'un acteur peut être rendu un peu plus complexe. Il est possible aussi d'étendre le service createTwoPartiesAndRelation pour un support de plusieurs acteurs avec des relations croisées.
objet : documentation des fonctions génériques de création des acteurs langue de la page de référence : Français auteur : Nicolas
