Héritage d'objet métier

Un objet métier peut hériter des règles de gestion d'un autre objet métier en référençant celui-ci comme son parent. Un objet métier enfant peut aussi avoir lui-même des enfants, etc. Les règles d'un parent s'appliquent automatiquement pour tous ses enfants (aucune compilation requise, cela se fait immédiatement). Un objet métier enfant peut toujours introduire ses propres règles mais ne peut jamais supprimer ou ignorer une règle héritée.

L'illustration ci-dessous décrit un exemple d'héritage d'objet métier à plusieurs niveaux.

Diagramme d'arborescence. Au niveau supérieur, il y a l'objet métier parent, ici client générique. Ses objets métier enfants sont client humain et client professionnel. Le client professionnel a deux enfants : client d'entreprise et client de partenariat. Lorsqu'un type client humain est ajouté, un courrier de bienvenue est envoyé. Lorsqu'un client d'entreprise ou un client de partenariat est ajouté, un courrier de bienvenue est envoyé et son historique de crédit est vérifié.

Notez comme l'objet métier "Client commercial" étend ses règles parent afin d'imposer aussi une vérification de l'historique du crédit de tous les types de client associés à ses objets métier enfant.

La plupart des événements système d'objet métier permettent l'exécution de plusieurs algorithmes. Par exemple, plusieurs algorithmes de validation peuvent être définis pour un objet métier. Dans ce cas, le système exécute tous les algorithmes à tous les niveaux de la chaîne d'héritage, en commençant par l'objet métier parent de niveau supérieur et en descendant aux niveaux inférieurs.

D'autres types d'événement système permettent l'exécution d'un algorithme unique. Par exemple, vous pouvez avoir un algorithme Information pour formater la description standard d'une instance d'un objet métier. Pour ce faire, le système l'exécute au niveau le plus proche de l'objet métier traité.

Remarque :
Le parent et son enfant doivent référencer le même objet de maintenance.
Remarque :
Les structures de données ne sont pas héritées. Vous pouvez déclarer des schémas sur les objets métier parent, mais leurs enfants n'en héritent pas. Il est conseillé de concevoir des schémas d'objet métier enfant incluant le schéma de leur objet métier parent.
Remarque :
Les matrices d'interface utilisateur sont héritées. Lorsqu'il détermine si l'objet métier a une matrice IU à utiliser pour la présentation de l'interface utilisateur, le système recherche des matrices d'affichage et de maintenance liée à l'objet métier en tant qu'options. Si aucune matrice n'est définie pour l'objet métier d'identification, le système "remonte la chaîne" d'héritage jusqu'à ce qu'il trouve une matrice à utiliser. Ceci permet à un objet métier enfant d'être utilisé pour étendre les règles de gestion d'un objet métier parent, mais le fait hériter du comportement d'interface utilisateur de ce dernier. Pour plus d'informations, voir Un objet métier définit son interface utilisateur.
Remarque :
Utilisez l'héritage à bon escient. Il peut être intéressant de regrouper le comportement dans les objets métier parent afin d'éviter toute logique redondante et simplifier la maintenance, mais, avant de prendre cette décision, comparez les avantages que cela peut vous apporter par rapport à la transparence, car il n'est pas facile de tenir à jour une hiérarchie complexe d'objets métier.