Les ERP traités
- ADempiere/
Ofbiz en Francais
Architecture Générale
Aperçu du projet Apache OFBiz
Ecrit par: David E. JONES Dec 31, 2006
Traduit en Français par: Alain IVARS Mai 27, 2008
Licence: Apache Licence Version 2.0
Page Originale (en Anglais): http://docs.ofbiz.org/x/lQM
Page Traduction (en Français):
But
Le but de ce document est de vous donner un aperçu du Projet Open For Business d'un point de vue commercial. Il passera en revue certains des principes et motivations qui sous-tendent le projet, les principaux composants applicatifs et, une brève explication de l'organisation technique du système.
Les descriptions de fonctionnalités de ce document sont destinées à vous donner un aperçu de haut niveau du système. Pour de plus amples informations, vous pouvez regarder en plus la liste de fonctionnalités et les documents connexes.
Introduction
Open For Business (OFBiz) est une suite d'applications d'entreprise bâtie sur une architecture commune, utilisant des données communes, la logique et les processus de composants. Le couplage de nature lâche rend ces composants faciles à comprendre, à étendre et personnaliser.
Avec les outils et l'architecture de OFBiz, il est facile de développer efficacement et de maintenir des applications d'entreprise. Il est donc possible pour nous qui sommes les créateurs et mainteneurs du projet de relâcher rapidement de nouvelles fonctionnalités et de maintenir les fonctionnalités existantes sans effort. Cela rend également facile la personnalisation et l'extension des fonctionnalités lorsque vous avez un besoin spécifique.
L'architecture à elle seule fait qu'il est plus facile pour vous de personnaliser les applications à vos besoins, mais beaucoup des meilleurs points de flexibilité dans le système n'aurait pas de sens et serai même impossible si le système n'avait pas été distribuée en tant que logiciel libre. OFBiz est sous licence Apache version 2,0 qui, vous accorde le droit de personnaliser, de prolonger, de modifier, de remanier, revendre, ainsi que de nombreuses autres utilisations potentielles du système.
Aucune restriction n’est imposée à ces activités parce que nous pensons qu'elles sont nécessaires pour une utilisation efficace de ce type de logiciel. Contrairement à d'autres licences open source, telles que la GPL, vos modifications n'ont pas à être publié en open source. Il y a des avantages évidents pour des certaines d'améliorations, corrections et ajouts au projet de base, comme certains changements de caractéristiques ou des renseignements confidentiels qui ne doivent pas être divulgués au public. Pour cette raison, OFBiz utilise la Licence Apache version 2,0 qui ne l'exige pas. Pour de plus amples renseignements sur les licences open source voir l'Open Source Initiative (OSI) Web site www.opensource.org.
Un autre avantage de ce modèle open source est que nous recevons constamment des commentaires des utilisateurs du logiciel. Nous avons reçu d'innombrables corrections de bugs, suggestions d'amélioration, et des conseils des meilleures pratiques d'affaires de la part des utilisateurs et de la part utilisateurs potentiels de OFBiz. Bon nombre des meilleures fonctionnalités dans le projet ont été inspirés par certains commentaires ou des suggestions envoyé à la mailing listes associés au projet. Avec des dizaines d'organisations utilisant le logiciel et probablement des centaines de sites déployés en utilisant une pièce ou un autre du projet. Nous recevons généralement 20-30 e-mails chaque jour sur le projet.
Pour faire en sorte que notre fonction soit utile en temps voulu, nous avons toujours commencé par la recherche de normes publiques et l'usage de n'importe quel composant sur lequel nous travaillons. Cela nous aide à soutenir et utiliser les vocabulaires et nous donne un instantané d'options et de fonctionnalités qui ne peuvent être atteint que par des normes et des efforts de groupe. Cela ouvre également les portes vers un avenir flexible pour la communication avec d'autres systèmes qui sont construits autour des mêmes normes, tant au sein de votre organisation qu’en partenariat ou d'autres organisations.
Les applications et composants applicatifs fournis avec le système vous fournirons une large et flexible base qui peut être utilisé tel quel avec les meilleures pratiques fondées sur les designs, et adapté à vos propres besoins. Les applications facilitent la gestion de toutes les parties, des produits de la comptabilité, du service à la clientèle, des ressources internes et la gestion d'actifs.
Les principaux composants applicatifs
Grâce à la collaboration de cette grande communauté et un effort de développement en cours, OFBiz souhaite y inclure des caractéristiques qui automatisent tous les aspects de l’information et des connaissances de l'entreprise. Au début de l'élaboration et la conception du projet, nous étions à la recherche d'un bon premier modèle de données à utiliser comme une base pour le système.
Nous avons étudié d'autres ERP et CRM et nous avons étudié les différentes générales et spécifiques au système avant de trouver dans des livres « The Data Model Resource Book, Revised Edition, Volumes 1 and 2 » par Len Silverston. Après quelques semaines de traduction de la logique des modèles de données décrites dans ces livres, sur une organisation souple et normalisée des modèles physique de données, nous avions notre organisation initiale du système. Depuis cette époque, le premier modèle de données est passé par des centaines de révisions et des améliorations fondées sur la vie réelle l’utilisation du système et la compatibilité avec des dizaines des normes publiques. En raison de la souplesse de l'architecture du système, il est facile d'apporter des modifications au modèle de données. Cela est nécessaire pour l'amélioration en cours du projet et rend facile pour vous d'apporter des modifications qui répondent à vos besoins spécifiques.
Les applications de haut niveau et la logique applicative des composants sont organisées avec une structure presque la même que celle du modèle de données. Une fois que l'organisation d'un niveau du système est comprise, il peut évolué vers d'autres niveaux avec très peu d'efforts.
Ce qui suit est un bref aperçu des principaux domaines fonctionnels du système. Beaucoup d'entre eux ont des fonctionnalités qui existent dès maintenant et ont tous les éléments de données définis qui couvrent les besoins de cette partie du système. Quand une fonctionnalité est mise en œuvre, nous affinons sans cesse son modèle de données, mais les principales définitions des éléments de données sont en place. Alors, n'oubliez pas que beaucoup, mais pas la totalité, des fonctionnalités décrites ici sont misent en œuvre.
Données communes
La partie des données communes dans le système comprend des entités telles que les frontières géographiques, les unités de mesure, les codes d'état, les énumérations, et ainsi de suite. La plupart de ces données ne sont que les semences de données importé lorsque le système est installé et changent généralement très peu au fil du temps. Les limites géographiques et autres données SEED sont basées sur l'ISO et d'autres normes.
Content Entity (Entité de Contenu)
Les Content Entity sont utilisées pour le suivi des données, elles structurent les ressources en contenu généraux et en connaissances. Elles comprennent de nombreux concepts tels que: une séparation de l'information et l'organisation des données, permettant à une ressource d’être utilisé dans de nombreuses structures d'organisation aux contenu flexible, y compris une libre association sous forme de graphiques ou organisation plus limitée dans des arbres, des listes, des cartes nommées, des modèles, etc., la spécification de méta-donnée de contenu et des ressources de données qui peuvent être utilisé pour organiser implicitement et explicitement à la description de l'information. Les pièces de contenu peuvent être en divers formats texte et binaires décrites par des types de codage MIME.
Une fois que les outils d'entretien généraux de l'information sont en place, des outils plus avancés tels que les mots clé, les méta données fondées, et la recherche intelligentes de textes permet de créer automatiquement la structure ou d'autres méta-données qui peuvent être utilisées pour permettre, à l'échelle de l'entreprise la création de documents et la gestion des connaissances.
Les Content Entity peuvent aussi comporter des informations sur le Web, des contenus tels des pages et l'interaction avec le contenu incluant des visites d'un site (ou application) et des informations sur toutes les demandes envoyées au site. Cette option est utile pour suivre ce que les utilisateurs font avec une application de sécurité, de mise sur le marché, la facilité d'utilisation et pour d'autres raisons.
Security Entity (Entité de Sécurité)
Les Security Entity sont utilisées pour contrôler l'accès à différentes parties du système, des connexions utilisateurs à des comptes, vérifier les données de connexion, l'autorisation de données, etc. Plus restrictives, une sécurité supplémentaire est accomplie par la Party Entityet l'association des Party Entity à diverses autres données dans certains rôles. Par exemple, un utilisateur peut avoir une autorisation pour visualiser et modifier toutes les données de produits et un autre utilisateur à la permission pour visualiser et modifier les données de produits si cet utilisateur est associé comme une vendeur des produits de cette catégorie.
Party Entity (Entité de Personne)
Une Party Entity peut être une personne ou un groupe de Party Entity. Un groupe de Party Entity pourrait être une société, une organisation au sein de l'entreprise, un fournisseur, un client, etc. Les informations qui décrivent les parties ou qui sont directement liée aux parties sont contenues dans ces entités.
Le mécanisme de Contact est un type de données relatives, qui a des données tels que les adresses postales, les numéros de téléphone, les adresses e-mail, les URL Internet. Les Rôles de Partie sont par exemple: clients, fournisseurs, employés, manager, vendeur, etc. En général, une partie unique va interagir avec les différentes parties du système dans de nombreux rôles différents.
Un autre type de données qui s’intègrent dans une Party Entity est l'information sur la communication et les accords entre les parties. Dans le domaine de la gestion de la relation, une Party Entity contient également des informations sur des questions ou des problèmes lier à celle-ci. Ces entités sont utilisées en combinaison avec des Work Effort Entityafin de planifier et de suivre la recherche et la résolution de ces questions.
Product Entity (Entité de Produit)
Les Product Entity contiennent des informations sur les produits qui sont destinés à la vente ou pour une utilisation au sein d'une entreprise. Les Product Entity peuvent être des biens ou des services, il existe plusieurs types de marchandises, matières premières, sous-ensembles et produits finis. Une Product Entity inclut des informations descriptives sur les produits, mais elle n'est pas utilisée pour décrire les cas réels (le cas échéant) ou de biens matériels, c'est là que les objets Inventaire arrivent en ligne de compte. Un objet Inventaire contient des informations sur l'endroit où un bien est situé, l'état de ce bien, un numéro de série, la quantité en stock et la quantité disponibles pour des montants de promesse sur des biens non numéroté.
Les Product Entity peuvent être organisés en catégories de Product Entity. Un seul Product Entity peut être un membre de plusieurs catégories et même des catégories peut elle-même être des enfants de plusieurs autres catégories et peuvent avoir de multiples catégories enfants. Les Product Entity peuvent également être associés à d’autres pour désigner des notions comme des variantes du produit, des ventes croiser, la commercialisation des lots, etc.
Les catégories peuvent être associés à différents catalogues. Un catalogue de Product Entity est essentiellement un point de départ pour toutes les informations relatives à un ensemble particulier de produits à être vendus. La gestion de la promotion de stocks peut être associés à chaque catalogue de sorte que différents canaux de distribution peuvent se comporter différemment, même avec le même ensemble de produits sous-jacents.
Pour modeler avec souplesse les différents types de caractéristiques qu’ont souvent les produits, une Product Entity peut définir des familles de fonctionnalités et des caractéristiques qui peuvent être appliquées aux produits. Par exemple, vous pourriez dire que cette chemise est de grande taille et est de couleur bleue. La taille et la couleur sont des types de caractéristiques et grandes et bleu sont les caractéristiques appliquées à ce produit.
De multiples prix peuvent être associés à un seul et même produit, comme plusieurs coûts. Différents prix peuvent être spécifiées pour les différentes monnaies, différents ensembles d'installations (ou magasins), et pour différentes périodes.
C'est un bon endroit maintenant pour vous présenter la large utilisation de la date effective dans OFBiz. Il y a deux domaines couramment utilisés pour exprimer les dates d'entrée en vigueur: DateDeDébut et DateDeFin. Dans le prix des produits par exemple la DateDeDébut et DateDeFin sont utilisés pour indiquer que le prix sera à une certaine date et expirera à une certaine date et heure. Cela peut être utilisé pour conserver un historique de l'évolution des prix, et à gérer efficacement les prix promotionnel temporaire.
En plus de préciser explicitement un prix, il y a aussi des entités et la logique qui utilise les entités, d'avoir des règles sur les prix. Par exemple vous pouvez créer une règle qui est en vigueur pour une certaine période de temps qui met tous les produits dans une certaine catégorie de la vente. Où, vous pouvez donner des prix spéciaux à des clients ou des groupes de clients avec une règle simple.
Order Entity (Entité de Commande)
Les Order Entitysont utilisées pour gérer de l'information sur les ventes, les bons de commande et, de l'information menant à une commande. Par exemple, une demande pour un produit spécifique ou présentant une caractéristique spéciale est présentée par un client, cette demande sera suivie par des Order Entity.
La demande peut être suivi et transformé en une exigence qui peut être utilisé pour créer une Work Effort Entity(une tâche, par exemple, voir Work Effort Entityci-après) à été créé pour satisfaire l'exigence de la demande. Une fois une demande client faite, une cotation peut être produite, si elle est acceptée par le client, elle peut être utilisé pour créer une commande. Une fois que la commande est remplie, une facture peut être créé par l'ordonnancier. Les factures font partie de l’Accounting Entitydécrite ci-dessous.
Les Order Entity sont composées d’une en-tête et d’un nombre quelconque de lignes et d’adaptations qui décrivent le détail de la commande. Il y a plusieurs éléments d'information relatifs à la commande qui peuvent être associé dans l'en-tête avec une personne, et plusieurs lignes articles commandés. Les exemples comprennent les préférences de l'expédition et de destination d'un envoi d'une commandes qui doit être la même pour toutes les rubriques, ou doit être différente pour chacun d'eux.
Les ajustements sont utilisés pour contenir des informations sur les choses qui changent le prix d'une commande, des biens qui ne sont pas réels ou des services vendus ou achetés. Les exemples incluent les taxes, l'expédition, les réductions, les suppléments, etc. Un ajustement peut être soit un montant forfaitaire, un montant forfaitaire par quantité ou un pourcentage du total partiel de la totalité de la commande ou de la ligne en question qui y est associée. Les taxes et frais d'expédition sont traités comme des cas particuliers et chaque ajustement peut préciser si elle doit ou non être inclus dans le sous-total de la taxe et/ou le sous-total pour l'expédition.
Les préférences de paiement peuvent être suivis lorsqu’un ordre est créé pour automatiser le paiement une fois qu’une facture est créée. Cela est particulièrement utile pour le paiement par carte de crédit ou autres moyens électroniques. Si aucune préférence de paiement n’est spécifiée, alors un standard de facturation et du processus de la facturation peut être utilisé.
Facility Entity (Entité d’Instalation)
Une Facility Entity est un bâtiment ou autre lieu d'implantation. On peut citer les entrepôts, les magasins, les immeubles de bureaux, des chambres individuelles dans un grand centre, des quais de chargement, etc. En général, une Facility Entity doit avoir des mécanismes contacts qui lui sont associés comme une adresse postale et/ou un numéro de téléphone.
Les Facility Entity peuvent être regroupés en Facility group qui à leur tour, peuvent être contenues dans d'autres Facility group. Exemples de groupes comprennent des chaînes, des districts, des régions et des groupes spéciaux utilisés pour la commercialisation ou la fixation des prix des produits.
Les articles d’Inventaire peuvent être associés à une Facility Entity et même un emplacement spécifique au sein d'un établissement. Les emplacements des Facility Entity peuvent être suivis et gérés indépendamment des articles d’Inventaires qu'ils contiennent pour faciliter la gestion des espaces d'entreposage des objets.
Les Party Entity peuvent être associés avec d’autre Facility Entity pour représenter où une personne travaille, une organisation qui contrôle ou exploite cette Facility, qui gère cette Facility, etc.
Shipment Entity (Entité d’Expedition)
Les Shipment Entity sont utilisées pour suivre les expéditions et pour entrée des articles dans l'inventaire ou de sortir des articles de l’inventaire.
Un envoi est constitué de plusieurs éléments, comme une commande, représenté une certaine quantité d'un produit spécifique. Lorsque ils sont reçus, ils peuvent être conciliée avec un bon de commande et l'information de suivie de l'envoi est gérée par la Shipment Entity.
Quand un Point d’inventaire est délivré pour un envoi sortant, il est associé à un aide-mémoire qui peut être préparé pour de multiples routes d’expéditions de manière plus efficace pour le chemin de ramassage dans l'entrepôt ou pour un autre établissement.
Les envois de colis peuvent être créés pour représentent un boîtier unique ou unité de chargement. Une seule boîte peut contenir plusieurs objets Shipment Entity, même des éléments de différents Shipment Entity en supposant qu'ils vont vers la même destination.
La Route d’une Shipment Entity est utilisées pour fractionner un voyage d’envois en plusieurs segments de route. Un segment de route pour un envoi pourrait être un transporteur commercial tandis qu'un autre pourrait être un transporteur privé ou un camion appartenant à la société.
Accounting Entity (Entité de Comptabilité)
Les Accounting entity sont organisées en fonction de l'âge et des principes généralement acceptés tels que la double entrée comptable, un grand livre des comptes hiérarchiques, les revues et l'affichage des transactions et entrées correspondantes. La structure est principalement basée sur l'OMG GL standard et le travail qui a été fait sur un AR/AP extension de la norme OMG GL. Cela correspond assez bien avec d'autres normes telles que l'initiative ebXML et OAGIS.
Les Accounting entity sont structurées de telle sorte que les comptes de plusieurs organisations peuvent être gérés. Les multiples organisations pourraient être plusieurs entreprises, ou services, ou d'autres organisations au sein d'une entreprise. Chaque organisation peut avoir plusieurs comptes GL associés de manière à ce qu'il puisse fonctionner avec ses propres sous-ensembles de la maîtrise du tableau des comptes. Chaque organisation peut aussi avoir son propre ensemble de revues de flexibilité, même si l'utilisation de journaux devraient être aussi minimes que possible en faveur de laisser le système automatiquement créer et publier les transactions basées sur les événements déclenchés par des procédures et des documents comme les bons de commande, factures, inventaire des transferts, des paiements, recettes, etc.
Il existe également des entités en place pour la budgétisation et la réconciliation des budgets réels compte GL soldés pour une période de l'exercice. Ah oui, il y a aussi des entités utilisés pour suivre la période fiscale des exercices et d'autres entités tenancière de résumés des résultats pour les comptes dans des périodes précises.
L’Accounting entity permet de suivre les biens immobilisés. Cela comprend les informations d'amortissement en sus de l'entretien, la planification des immobilisations (avec les Work Effort Entity), etc.
Marketing Entity (Entité de Marketing)
Les Marketing Entity sont utilisés pour le suivi des informations relatives aux campagnes de marketing et d'informations connexes, telles que les listes de contact (mailing, e-mail, ou listes d’appelants) et des codes de suivi. Des codes de suivi sont principalement utilisés dans les systèmes automatisés pour garder la trace de l'endroit où un client est venu et peut être utilisé pour la commission et en plus dans le buts d'analyser l'efficacité des campagnes de marketing y compris la publicité, des partenariats ou affiliations, etc.
Work Effort Entity (Entité L'effort de travail)
Un Work Effort Entity peut être l'une des nombreuses choses, y compris une tâche, un projet, phase du projet, point à faire, d'agenda, un flux ou un flux d'activité.
Les flux sont un cas particulier et sont gérés par le moteur de workflow OFBiz. Un flux de travail est essentiellement un processus semi automatisé qui implique à la fois des activités automatiques menées par l'ordinateur et des activités manuelles effectuées par une personne ou un autre système externe contrôlé par un humain. Le moteur de processus workflow est défini dans les spécifications des entités inspirées de la Workflow Management Coalition (WfMC.org). Les fichiers XPDL peuvent être importés dans ces entités et le flux défini peut être invoquée par divers moyens. Le moteur de workflow garde une trace de tout ce qui a été fait et qui doit être fait pour les processus qu'il s'exécute.
Il y a aussi les Work Effort Entity pour garder la trace des feuilles de temps et le taux de rémunération de certaines Parties effectuant des travaux efforts. En outre diverses autres ressources peuvent être suivis comme les immobilisations, installations, etc.
Lorsque les Work Effort Entity sont utilisés pour la fabrication ou une modification des produits, les produits et des stocks consommés et produit par le Work Effort Entity spécifiques peuvent être suivis.
Human Resources Entity (Entité Ressources humaines)
Les Human Resources Entity sont utilisées pour assurer le suivi des positions, les responsabilités, les compétences, l'emploi, la résiliation, les avantages sociaux, la formation, payer les grades et les préférences des états de paie, les études de performance, de curriculum vitae, les applications et d'autres informations connexes aux ressources humaines.
Architecture and System Organization (Architecture et organisation du système)
L'architecture est vraiment juste un mot de fantaisie pour l'organisation et la composition de composants applicatifs. Il existe de nombreux "outils" à disposition dans le cadre de Java, J2EE et OFBiz et dans le cadre de base qui peuvent être utilisés conjointement de manière à organiser efficacement les données et la logique, pour fournir des interfaces avec d'autres systèmes, et de créer des interfaces utilisateurs.
Entities and Services (Entités et Services)
La plupart des éléments de base dans OFBiz sont des entités et des services. Une entité est une construction de données relationnelle qui contient un certain nombre de champs et peut être associée à d'autres entités. Les Entités de base correspondent à des structures de base de données. Il y a également un type d'entité que l'on appelle une « entité de vue » qui peut être utilisés pour créer une entité virtuelle d'autres entités combiner ensembles en se joignant à d'autres entités. Ces constructions peuvent être utilisées pour résumer et grouper des données, et en général pour préparer pour la visualisation ou l'utilisation dans un programme.
Dans beaucoup d'architectures de données, la couche de persistance contient à elle seule des centaines de milliers ou des millions de lignes de code qui doit être maintenu car le système est développé et personnalisé. Avec ce moteur d’entité c’est environ quelques milliers de lignes de définitions de données XML qui pilote une API dynamique et facile. Même les programmeurs les moins expérimentés peuvent devenir productif avec cet outil en quelques jours et ne jamais avoir à apprendre tout le SQL. Il prend cela en charge pour vous!
Vous avez probablement entendu parler de "Web Services" qui ce sont répandues dans tous les coins de l'industrie du logiciel. Le système OFBiz, utilise non seulement le modèle "Web Services" pour communiquer avec d'autres systèmes, mais il utilise également le modèle "Web Services" en interne pour proposé une interface propre et facile à utiliser, permettant de créer et de gérer les logiques de composants d’une entreprise.
Un service est un processus simple qui effectue une opération spécifique. Une définition du service est utilisée pour définir une entrée et une sortie de paramètres que le service consomme et produit. Les données transmises à ce service peuvent être validés automatiquement par l’utilisation d’un fichier de grammaire avant l’appel de la logique. Après l’exécution d’un service, les résultats peuvent être validées de la même manière.
D'autres services peuvent être gérées automatiquement à différents points de la gestion d'un service en utilisant des règles de l'événement-condition-action (ECA), pour désigner que d'autres services devraient être appelés, et dans quelles circonstances. Cette logique permet d’être prorogé sans modification de la logique initiale et permet au système d'être proprement organisé de telle sorte que chaque service effectue une simple tâche spécifique.
Les services peuvent être mis en oeuvre de différentes manières afin de permettre plus facilement aux ingénieurs de faire correspondre les outils disponibles à la tâche à accomplir. Le moteur rend également facile de garder une trace de la logique des composants du système, qui existe dans des centaines de fichiers différents, et même sur plusieurs ordinateurs utilisés à l'intérieur de l'entreprise ou sur des ordinateurs d'une entreprise partenaire.
Workflow and Rules Workflow (Workflow et Règles de Workflow)
Le moteur de workflow, qui est décrit brièvement dans l'effort de travail ci-dessus, peut être utilisés pour automatiser des processus d'affaires composé à la fois de processus manuel (effectué humainement) et des processus automatiques (effectué par ordinateur). Les flux peuvent être appelés et automatisés, toutefois les activités au sein d'un flux de travail peuvent appeler une combinaison de services de petits composants logiques qui permettent une flexibilité illimitée.
Le but des outils de workflow est d'automatiser et de suivre les processus d'affaires complexes. Ils peuvent aider à vous assurer que vos politiques sont suivies et que des tâches importantes ne sont pas perdus dans le chaos et la confusion. Un bon exemple en est le « Order Manager » dans OFBiz qui est basée flux de travail. Quand une commande est passée, un flux de travail est commencé et suivi par l'approbation et l'exécution de la commande. Avec cet outil, il est facile de voir ce qui est arrivé à un bon de commande spécifique et ce qu'il reste à faire avec la commande.
Il existe de nombreux autres exemples de processus qui peuvent bénéficier de ce type de gestion. Par exemple: la création de contenus et de publications, numéros clients, requêtes de gestions des services, la gestion du cycle de vente, et tout autre processus d'affaires qui implique la coordination de différentes personnes dans des rôles différents.
Le moteur de règles dans OFBiz est essentiellement un autre langage de programmation qui se fonde sur des concepts complètement différents des langages procéduraux de programmation comme Java, Basic, C, Cobol, etc. Les faits et les règles sont déclarées et ensuite utilisés dans une des deux façons suivantes: 1) demander si une affirmation est vrai et montrer toutes les preuves de l'affirmation, et 2) présenter toutes les informations disponibles en demandant par le moteur de règles, à tous les autres produits d'information possible, en tenant compte des faits et des règles qu'il connaît.
Les règles du moteur peuvent être utilisés pour de nombreuses applications différentes. Elles sont les plus utiles pour l'aide à la décision et pour aider l'homme à analyser les situations qui sont trop complexes à faire sur papier ou de tête ou par quelque moyen que ce soit en raison du temps qui serait en cause. En utilisant les règles comme des contraintes, de trouver toutes les solutions valables à un des problèmes tels que: l’assignement des portes d’un aéroport ou le routage d’un camion de livraison afin d’optimiser le temps; de permettre une application cohérente des règles que l'homme peut omettre ou oublier et ce quel que soit l'expérience de cette personne.
Web Framework and XML Mini-Languages (Languages Web et XML cadre mini-Langues)
Il existe de nombreux outils utiles dans le cadre de base OFBiz qui adresse des points de difficulté du Web, comme les applications de l'entreprise fondé sur des client-serveur et des peer-to-peer. Un outil existe pour simplifier l'utilisation de fichiers de données à plat ce qui rend plus facile à l’intégration dans les systèmes. Divers outils existent pour l'organisation et de structuration sur le Web des contenus et des applications avec une séparation souple de la logique et de la présentation. Ces outils ainsi que la norme J2EE, Java et d'autres outils font qu’il est facile pour le système de communiquer avec des utilisateurs et d'autres systèmes.
Pour que ces outils du cadre de base soient plus faciles à utiliser un autre composant appelé un Mini-langue XML a été créé pour permettre à un ingénieur ou un autre utilisateur de créer un fichier XML simples et des instructions bien définies, que le système peut comprendre et exécuter. Exprimant sa logique dans une "méthode simple", il faut souvent seulement un tiers de taille pour un code équivalent Java et qui est beaucoup plus facile à lire et à modifier pour les semi-utilisateurs techniques. Le traitement de formulaire de saisie, la composition de services dans des services plus grand, et interagir avec les données dans la base de données commune sont des choses que l'on peut faire facilement avec cet outil.
Conclusion
L'Open For Business Project est un effort de collaboration impliquant un grand groupe d'utilisateurs et de développeurs qui est animée par une petite équipe centrale. Les applications cadre et les composants sont utilisés dans une grande variété d'entreprises et d’applications et sont fortement personnalisé dans de nombreuses circonstances afin de répondre aux besoins des organisations en utilisant le logiciel.
Ce n'est possible et ne peut fonctionner efficacement et effectivement que comme un projet open source. Ceci est en contraste avec le style de la plupart des fournisseurs commerciaux qui limitent de nombreux usages possibles des extensions à leurs logiciels en passant par la conception limitative ou des restrictions dans l'octroi de licences afin d'extraire un plus grand profit de l'utilisation du logiciel. Une grande partie des premiers logiciels commerciaux étaient beaucoup plus flexible, plus ouvert et moins restrictif que de nombreux logiciels modernes. Comme cette tendance se poursuit, de plus en plus de développeurs et d’utilisateurs de logiciels commencent à envisager une alternative permettant plus de confiance.
Tous ceux qui contribuent au projet, y compris les animateurs, ont choisis de ne pas forcer d'autres qui l'utilisent à les payer, ils peuvent en tirer partie de plusieurs autres façons différentes. Souvent, vous constaterez que le système est très proche de ce dont vous avez besoin et qu’une petite quantité d'effort de votre part peut changer le système pour qu’il soit parfait pour vous. Si cet effort est fourni à la communauté, d'autres dans une situation similaire pourrons contribuer à améliorer et à maintenir votre contribution. Comme vous contributeur, vous pouvez librement mettre à niveau votre propre système avec d'autres améliorations dans le projet principal, sans avoir à vous soucier que vos modifications soit susceptibles d'être en conflit lors d’une mise à niveau.
En général OFBiz est destiné à fournir autant de valeur pour lesquelles vous serez prêt et heureux de contribuer quelque chose en retour et de maintenir l'effort en cours. Là encore, est un contraste avec l'approche commerciale qui veut forcer les utilisateurs à payer pour chaque droit d'utilisation ou de modification concernant le logiciel. L’approche open source permet le partage de l'information et que celle-ci puisse être exploité par toute dans la communauté pour améliorer l'utilisation du logiciel pour leurs propres besoins.
Ainsi, pour les animateurs du projet, que gagnons-nous pour tout le temps passé à la conception d'applications, l'écriture du code, et la réponse aux questions? Il remonte à la loi fondamentale de la récolte: récolter ce que vous vous semer. Plus a de valeur la chose fournit, plus elle vaut. Pour nous, c'est une occasion d'être à la croisée d'un tel projet et d’être impliqués à l'aider à croître au moins un peu. Cela nous donne la chance de travailler avec vous et de fournir des services en échange de revenus qui maintiennent le projet en cours.
Notre seul espoir est que vous serez en mesure dans le cadre du projet de tirer le plus de valeur comme nous en avons.
