r-io suitededuction docsA rule-free deduction strategy. For every objective it keeps the most pertinent function, assigns the most expert actors, wraps the resulting task graph into one sub-task dedicated to that objective, and chains these sub-tasks strictly one after the other. The campaign also explores preventive and corrective procedure combinations, streams progress reports, removes duplicate solutions and wires Exception_Flow and Event_Flow recoveries.
The generated process is not a flat scheduled graph: the top-level process contains one SubProcess_Task per objective, named after the objective, linked by Sequence_Flows in objective priority order. Each sub-task holds the complete task graph of the function chosen for its objective, with its assigned resources and its Exception_Flow recoveries.
Objectives_Manager and its Plans edges.Satisfies (with its pertinence property), Needs, Implies, Supports, Provides, Consumes relations of the collaborative model.satisfactionProperties: planner, actor selection mode, resource-combination cap, maximum number of solutions, campaign configuration (actualities, emerging/intrinsic and implementation potentialities with their procedures).Satisfies edge.Solution → Process → one SubProcess_Task per objective → Task/Sequence_Flow with expected dates and assigned resources.The dialog is not part of the host applications: it is a deduction strategy extension, a separate Angular bundle loaded at start-up and registered under the name returned by the backend strategy.
webjars/r-io/solution/strategy/extensions/deduction-strategy-extensions.json lists the runtime.js and main.js of the extension bundle.createNativeBasicBlocSatisfactionStrategyDialog, the value of getJavascriptFunction(); the host runs it when the strategy is chosen.POST …/r-ioga/solution/deduceSolutionASync with the satisfactionProperties.DeductionImpl.deduceASync finds the generator through ServiceLoader.META-INF/services/fr.emac.gind.workflow.AbstractProcessGenerator.RioDefaultPlanner; builds one sequential sub-task per objective.Entry point: doDeduceProcessFromOneObjectivesManager(campaign, mode, collaboration, knowledgeSpace, objectivesManager, data, project, resultsQueue).
satisfactionProperties gives the planner type (Default), the actor selection mode (PERSON_FIRST by default), the resource-combination cap, the maximum number of solutions, the move-improver flag and the campaign configuration. The campaign stops early when an objective has no impacted resource.
Each actuality or potentiality groups its objectives; an activated group gives one function to each of them (inner Cartesian product) and a NONE alternative is added per group (outer product). Candidate functions of each procedure objective are sorted by the pertinence of their Satisfies edge, read in one batched query.
For each objective, candidates are read by descending pertinence; a candidate is kept when at least one actor provides every function of its graph. The first kept candidate is the most pertinent function of the objective; the ordered list feeds the ALL_SOLUTIONS plan combinatorics. When no candidate survives, the collected repair hints are reported.
NativeBasicBlocPlanner is created without any ActorCandidateRanker: the inherited RioDefaultPlanner.solve enumerates resource assignments with ResourceAssigner and keeps, per objective, the assignments with the best expertise and the fewest unavailability slots.
For each objective, in plan order, its assigned tasks are scheduled on their own; every task gets an earliest start equal to the end of the previous objective's bloc. The scheduled graph (with its Exception_Flow recoveries) becomes a process wrapped into a SubProcess_Task named after the objective; its aggregated indicators are copied onto the wrapper.
The top-level process links Start → bloc 1 → bloc 2 → … → End. When emerging or intrinsic potentialities bring corrective procedures, the whole chain is wrapped into a Nominal SubTask; each correction is attached with an Event_Flow whose 2L condition checks that the actuality is active and generated by the selected potentiality.
Indicators are evaluated on every task and aggregated on the process. Reports and campaign indicators (tasks used, expertise, functions and resources counts) expand structural sub-tasks without a function, so the per-objective wrappers do not hide the real tasks.
A campaign-wide signature set drops equivalent solutions (same functions, actors, resources and procedures, including inside sub-tasks). Unique solutions are stored through the campaign manager; in FIRST_GOOD_SOLUTION mode the first one is published to the graph and the campaign ends.
previousEnd = null for solution in orderedSolutionsByObjective: # plan / priority order tasks = solution.graphAssignedTasks schedule = Scheduler(tasks, earliestStart = previousEnd) inner = createProcessFromScheduleTask(schedule, tasks) # Exception_Flow recoveries included bloc = SubProcess_Task(solution.objective.name, inner) # indicators copied on the wrapper bloc.expected = [min(task.start), max(task.end)] previousEnd = bloc.expected.end process = Start -> bloc1 -> bloc2 -> ... -> End if eventFlowCorrections: process = Start -> SubProcess_Task("Nominal SubTask", process) -> End + Event_Flow(nominal -> correction) for each correction
An objective bloc can only start once the previous bloc is over, even when their resources do not overlap. Inside a bloc, the Default scheduler keeps its usual behaviour (prerequisites, parallel tasks, actor and resource availability).
| Element | Where it lives | Built by |
|---|---|---|
| Objective bloc | Top-level process (or inside the Nominal SubTask) | wrapIntoSubTask(objectiveName, innerProcess) |
| Function tasks | Inside the objective bloc | createProcessFromScheduleTask on the objective's own schedule |
| Exception_Flow recovery (implementation potentiality) | Inside the objective bloc, attached to its task | ResourceTaskGraph · Task.tryCatchCorrections |
| Event_Flow correction (emerging / intrinsic potentiality) | Top-level process, from the Nominal SubTask | NativeBasicBlocPlanner.createProcess, same wiring as RioDefaultPlanner |
Captured in r-ioda after the CEP rules of the Gas Rapsodee and Intrusion Main Entrance sensors raised two actualities. Launch: header Action → Deduce solution → Deduce solution from one objectives manager, then Native Basic Bloc Satisfaction Strategy Process Deduction.
| Sub-task (published process) | Expected start | Inner tasks |
|---|---|---|
| Treats Presence detected | 23:44 | Put on safety equipment, Pick up communications equipment, Makes a round with the watchdog, Arrest the suspects with the surveillance dog, Retrieve the guard dog, Event report |
| Treats Analyze the gas leak | 00:00 | Cut off the local gas valve, Report the damage |
| Secured the site | 00:04 | Establish a security perimeter, Secured the site |
| Contact the center manager | 00:08 | Notify the authorities, Contact the center manager |
Each bloc starts exactly when the previous one ends. This scenario only raises actualities: no implementation or emerging potentiality is involved, so neither Exception_Flow nor Event_Flow appears in this process.
FIRST_GOOD_SOLUTION — procedure candidates are reduced to the most pertinent function per objective and only the last, fully specified combination is processed, so a NONE combination cannot silently drop a selected procedure. The campaign stops after the first unique persisted solution, which is also published to the graph.
ALL_SOLUTIONS — every procedure combination, every function plan (Cartesian product of the pertinence-ordered candidates) and every actor/resource assignment is explored; the signature set removes equivalent solutions. numberOfSolutions (−1 = no limit) caps the queued solutions across the whole campaign and ends it once reached.
MY_SOLUTION — a front-end presentation only: one function is picked per objective with radio buttons and the request is sent as FIRST_GOOD_SOLUTION.
combinations = cartesian(group bundles + NONE per group)
start = FIRST_GOOD ? last : 0
for combination in combinations[start:]:
deduceOneCombination(combination) # 4-task pipeline, awaited
if FIRST_GOOD and processed > 0: break
if ALL_SOLUTIONS and queued >= numberOfSolutions: break
report ENDED on the last combination, the first good solution
or when the solutions cap is reacheddeduce() returns immediately; a single-thread executor processes the combinations one after another, each through a fixed pool of four tasks linked by two queues closed by poison pills.
RUNNING, ENDED or CRASHED; cumulative counters and the solution estimate survive combination boundaries.plansQueue — PlanWithFunctionsNativeBasicBlocPlanner, which builds the sequential sub-task process; resource shortages become error results, not crashes.solutionQueue — planned solutionsScenarioResult; publishes the model synchronously in first-good mode.| satisfactionProperties key | Default | Used for |
|---|---|---|
selectedPlanningSolver | Default | Any other planner is refused (UnsupportedOperationException) |
actorsSelectionMode | PERSON_FIRST | PERSON_FIRST, GROUP_FIRST, ONLY_PERSON, ONLY_GROUP |
numberOfResourceCombinations | 30 (first good) · −1 (all) | Cap on enumerated resource assignments per main function |
numberOfSolutions | −1 | Campaign-wide solutions cap in ALL_SOLUTIONS |
campaignConfiguration | — | Actualities, emerging/intrinsic and implementation potentialities with their selected functions |
activeMoveImprover | false | Runs the “move nodes improver” on each objective bloc (requires a Google API key) |
objectivesManager · embeddedObjectivesManagerModel | — | Root of the deduction |
Extension bundle. The dialog lives in the workspace project gind-npm-strategy-deduction-native-basic-bloc-satisfaction (Angular target …-extension). Its form groups: solution mode, caps, Actuality Management, Emerging and Intrinsic Potentiality Management, selected objectives, Implementation Potentiality Management, actor selection mode, move tasks and planning solver.
Loading. DeductionStrategyExtensionLoaderService reads deduction-strategy-extensions.json (shipped by gind-webapp-generic-application-users, which also depends on the extension jar) and injects the scripts; the bundle registers itself in window.gindDeductionStrategyExtensions.
Host services. The extension runs its own zoneless Angular application but works on the host's already-initialised services (app, init, modal, core, models, solution and project services) passed through the extension context; it never imports the generic application's app.service.ts.
Objective blocs never overlap, even when their resources are independent: total duration is the sum of the blocs, not the critical path of a merged schedule.
With Event_Flow corrections the structure reaches three levels: Nominal SubTask → objective bloc → recovery sub-process. Consumers must expand structural sub-tasks (getEffectiveTasks).
Function ranking relies on the pertinence property (0–100) of Satisfies; equal or missing values keep the discovery order.
A second NgZone bound to the host's zone raises NG0909 and the dialog is never rendered.
The server serves the jar from its classpath: install the npm module while the server is stopped (a jar overwritten under a running JVM answers HTTP 500 “invalid LOC header”), then force a browser reload of runtime.js and main.js, which are cached.
Only the Default planner is supported; Choco and Cofiade stay disabled in the dialog.
Backend module java/backend/gind-governance/gind-governance-workflow-deduction-strategy-native-basic-bloc-satisfaction, package fr.emac.gind.workflow.deduction.
NativeBasicBlocSatisfactionProcessGenerator.javaSPI entry of the strategy.NativeBasicBlocSatisfactionStrategyDeductionCampaign.javaParameters, combinations, native ranking, four-task pipeline, solutions cap, publication.NativeBasicBlocPlanner.javaPer-objective scheduling, sub-task wrapping, sequential chaining, Event_Flow wiring.gind-governance-workflow-planner-default/…/RioDefaultPlanner.javaResource assignment, schedule-to-process conversion, Exception_Flow recoveries.gind-governance-workflow-deduction-strategy-abstract/…/AbstractDeductionStrategy.javaReports and campaign indicators, getEffectiveTasks.gind-npm-strategy-deduction-native-basic-bloc-satisfaction/src/Extension entry, dialog component, service, host-service token.gind-webapp-generic-application-users/…/deduction-strategy-extensions.jsonScripts loaded by the host applications.Une stratégie de déduction sans règles. Pour chaque objectif, elle retient la fonction la plus pertinente, affecte les acteurs les plus experts, place le graphe de tâches obtenu dans une sous-tâche dédiée à cet objectif et enchaîne ces sous-tâches strictement l’une après l’autre. La campagne explore aussi les combinaisons de procédures préventives et correctives, diffuse des rapports de progression, écarte les solutions en double et câble les reprises Exception_Flow et Event_Flow.
Le processus généré n’est pas un graphe ordonnancé à plat : le processus de premier niveau contient une SubProcess_Task par objectif, portant le nom de l’objectif, reliées par des Sequence_Flow dans l’ordre de priorité des objectifs. Chaque sous-tâche contient le graphe de tâches complet de la fonction choisie pour son objectif, avec ses ressources affectées et ses reprises Exception_Flow.
Objectives_Manager sélectionné et ses arêtes Plans.Satisfies (avec sa propriété pertinence), Needs, Implies, Supports, Provides, Consumes du modèle collaboratif.satisfactionProperties : planificateur, mode de sélection des acteurs, plafond de combinaisons de ressources, nombre maximal de solutions, configuration de campagne (actualités, potentialités émergentes/intrinsèques et d’implémentation avec leurs procédures).Satisfies.Solution → Process → une SubProcess_Task par objectif → Task/Sequence_Flow avec dates attendues et ressources affectées.Le dialogue ne fait pas partie des applications hôtes : c’est une extension de stratégie de déduction, un bundle Angular séparé chargé au démarrage et enregistré sous le nom renvoyé par la stratégie backend.
webjars/r-io/solution/strategy/extensions/deduction-strategy-extensions.json liste le runtime.js et le main.js du bundle d’extension.createNativeBasicBlocSatisfactionStrategyDialog, valeur de getJavascriptFunction() ; l’hôte l’exécute quand la stratégie est choisie.POST …/r-ioga/solution/deduceSolutionASync avec les satisfactionProperties.DeductionImpl.deduceASync trouve le générateur via ServiceLoader.META-INF/services/fr.emac.gind.workflow.AbstractProcessGenerator.RioDefaultPlanner ; construit une sous-tâche séquentielle par objectif.Point d’entrée : doDeduceProcessFromOneObjectivesManager(campaign, mode, collaboration, knowledgeSpace, objectivesManager, data, project, resultsQueue).
satisfactionProperties fournit le type de planificateur (Default), le mode de sélection des acteurs (PERSON_FIRST par défaut), le plafond de combinaisons de ressources, le nombre maximal de solutions, l’indicateur d’amélioration par déplacement et la configuration de campagne. La campagne s’arrête tôt quand un objectif n’a aucune ressource impactée.
Chaque actualité ou potentialité regroupe ses objectifs ; un groupe activé donne une fonction à chacun d’eux (produit cartésien interne) et une alternative NONE est ajoutée par groupe (produit externe). Les fonctions candidates de chaque objectif de procédure sont triées par la pertinence de leur arête Satisfies, lue en une seule requête groupée.
Pour chaque objectif, les candidates sont lues par pertinence décroissante ; une candidate est conservée quand au moins un acteur fournit chaque fonction de son graphe. La première candidate conservée est la fonction la plus pertinente de l’objectif ; la liste ordonnée alimente la combinatoire des plans en ALL_SOLUTIONS. Quand aucune candidate ne survit, les pistes de réparation collectées sont rapportées.
NativeBasicBlocPlanner est créé sans ActorCandidateRanker : le RioDefaultPlanner.solve hérité énumère les affectations de ressources avec ResourceAssigner et garde, par objectif, les affectations de meilleure expertise et avec le moins de créneaux d’indisponibilité.
Pour chaque objectif, dans l’ordre du plan, ses tâches affectées sont ordonnancées seules ; chaque tâche reçoit un démarrage au plus tôt égal à la fin du bloc de l’objectif précédent. Le graphe ordonnancé (avec ses reprises Exception_Flow) devient un processus placé dans une SubProcess_Task portant le nom de l’objectif ; ses indicateurs agrégés sont recopiés sur l’enveloppe.
Le processus de premier niveau relie Start → bloc 1 → bloc 2 → … → End. Quand des potentialités émergentes ou intrinsèques apportent des procédures correctives, toute la chaîne est placée dans une Nominal SubTask ; chaque correction est rattachée par un Event_Flow dont la condition 2L vérifie que l’actualité est active et générée par la potentialité sélectionnée.
Les indicateurs sont évalués sur chaque tâche et agrégés sur le processus. Les rapports et indicateurs de campagne (tâches utilisées, expertise, nombres de fonctions et de ressources) déplient les sous-tâches structurelles sans fonction : les enveloppes par objectif ne masquent pas les vraies tâches.
Un ensemble de signatures à l’échelle de la campagne écarte les solutions équivalentes (mêmes fonctions, acteurs, ressources et procédures, y compris dans les sous-tâches). Les solutions uniques sont stockées via le gestionnaire de campagnes ; en mode FIRST_GOOD_SOLUTION, la première est publiée dans le graphe et la campagne s’arrête.
finPrecedente = null pour solution dans solutionsOrdonneesParObjectif : # ordre du plan / des priorités taches = solution.graphAssignedTasks ordo = Scheduler(taches, demarrageAuPlusTot = finPrecedente) interne = createProcessFromScheduleTask(ordo, taches) # reprises Exception_Flow incluses bloc = SubProcess_Task(solution.objectif.nom, interne) # indicateurs recopiés sur l’enveloppe bloc.attendu = [min(tache.debut), max(tache.fin)] finPrecedente = bloc.attendu.fin processus = Start -> bloc1 -> bloc2 -> ... -> End si correctionsEventFlow : processus = Start -> SubProcess_Task("Nominal SubTask", processus) -> End + Event_Flow(nominale -> correction) pour chaque correction
Un bloc d’objectif ne peut démarrer qu’une fois le bloc précédent terminé, même quand leurs ressources ne se chevauchent pas. Dans un bloc, l’ordonnanceur Default garde son comportement habituel (prérequis, tâches parallèles, disponibilité des acteurs et des ressources).
| Élément | Emplacement | Construit par |
|---|---|---|
| Bloc d’objectif | Processus de premier niveau (ou dans la Nominal SubTask) | wrapIntoSubTask(nomObjectif, processusInterne) |
| Tâches de la fonction | Dans le bloc d’objectif | createProcessFromScheduleTask sur l’ordonnancement propre à l’objectif |
| Reprise Exception_Flow (potentialité d’implémentation) | Dans le bloc d’objectif, attachée à sa tâche | ResourceTaskGraph · Task.tryCatchCorrections |
| Correction Event_Flow (potentialité émergente / intrinsèque) | Processus de premier niveau, depuis la Nominal SubTask | NativeBasicBlocPlanner.createProcess, même câblage que RioDefaultPlanner |
Captures réalisées dans r-ioda après que les règles CEP des capteurs Gas Rapsodee et Intrusion Main Entrance ont levé deux actualités. Lancement : en-tête Action → Deduce solution → Deduce solution from one objectives manager, puis Native Basic Bloc Satisfaction Strategy Process Deduction.
| Sous-tâche (processus publié) | Début attendu | Tâches internes |
|---|---|---|
| Treats Presence detected | 23:44 | Put on safety equipment, Pick up communications equipment, Makes a round with the watchdog, Arrest the suspects with the surveillance dog, Retrieve the guard dog, Event report |
| Treats Analyze the gas leak | 00:00 | Cut off the local gas valve, Report the damage |
| Secured the site | 00:04 | Establish a security perimeter, Secured the site |
| Contact the center manager | 00:08 | Notify the authorities, Contact the center manager |
Chaque bloc démarre exactement à la fin du précédent. Ce scénario ne lève que des actualités : aucune potentialité d’implémentation ou émergente n’intervient, ce processus ne contient donc ni Exception_Flow ni Event_Flow.
FIRST_GOOD_SOLUTION — les candidates des procédures sont réduites à la fonction la plus pertinente par objectif et seule la dernière combinaison, entièrement spécifiée, est traitée : une combinaison NONE ne peut donc pas écarter en silence une procédure sélectionnée. La campagne s’arrête après la première solution unique persistée, aussi publiée dans le graphe.
ALL_SOLUTIONS — toutes les combinaisons de procédures, tous les plans de fonctions (produit cartésien des candidates ordonnées par pertinence) et toutes les affectations acteurs/ressources sont explorés ; l’ensemble de signatures écarte les solutions équivalentes. numberOfSolutions (−1 = sans limite) plafonne les solutions mises en file sur toute la campagne et la termine une fois atteint.
MY_SOLUTION — une présentation front uniquement : une fonction est choisie par objectif avec des boutons radio et la requête part en FIRST_GOOD_SOLUTION.
combinaisons = cartesien(bundles de groupe + NONE par groupe)
debut = FIRST_GOOD ? derniere : 0
pour combinaison dans combinaisons[debut:] :
deduceOneCombination(combinaison) # pipeline à 4 tâches, attendu
si FIRST_GOOD et traitees > 0 : arrêt
si ALL_SOLUTIONS et enFile >= numberOfSolutions : arrêt
rapporter ENDED sur la dernière combinaison, la première bonne solution
ou quand le plafond de solutions est atteintdeduce() rend la main immédiatement ; un exécuteur mono-thread traite les combinaisons l’une après l’autre, chacune via un pool fixe de quatre tâches reliées par deux files fermées par des pilules empoisonnées.
RUNNING, ENDED ou CRASHED ; les compteurs cumulés et l’estimation du nombre de solutions survivent aux frontières de combinaison.plansQueue — PlanWithFunctionsNativeBasicBlocPlanner, qui construit le processus en sous-tâches séquentielles ; les pénuries de ressources deviennent des résultats d’erreur, pas des crashs.solutionQueue — solutions planifiéesScenarioResult ; publie le modèle en synchrone en mode première bonne solution.| Clé de satisfactionProperties | Défaut | Usage |
|---|---|---|
selectedPlanningSolver | Default | Tout autre planificateur est refusé (UnsupportedOperationException) |
actorsSelectionMode | PERSON_FIRST | PERSON_FIRST, GROUP_FIRST, ONLY_PERSON, ONLY_GROUP |
numberOfResourceCombinations | 30 (première bonne) · −1 (toutes) | Plafond d’affectations de ressources énumérées par fonction principale |
numberOfSolutions | −1 | Plafond de solutions sur toute la campagne en ALL_SOLUTIONS |
campaignConfiguration | — | Actualités, potentialités émergentes/intrinsèques et d’implémentation avec leurs fonctions sélectionnées |
activeMoveImprover | false | Exécute le « move nodes improver » sur chaque bloc d’objectif (clé Google API requise) |
objectivesManager · embeddedObjectivesManagerModel | — | Racine de la déduction |
Bundle d’extension. Le dialogue vit dans le projet du workspace gind-npm-strategy-deduction-native-basic-bloc-satisfaction (cible Angular …-extension). Son formulaire regroupe : mode de solution, plafonds, Actuality Management, Emerging and Intrinsic Potentiality Management, objectifs sélectionnés, Implementation Potentiality Management, mode de sélection des acteurs, tâches de déplacement et planificateur.
Chargement. DeductionStrategyExtensionLoaderService lit deduction-strategy-extensions.json (livré par gind-webapp-generic-application-users, qui dépend aussi du jar de l’extension) et injecte les scripts ; le bundle s’enregistre dans window.gindDeductionStrategyExtensions.
Services de l’hôte. L’extension exécute sa propre application Angular sans zone mais travaille sur les services déjà initialisés de l’hôte (services app, init, modal, core, models, solution et project) transmis par le contexte d’extension ; elle n’importe jamais le app.service.ts de l’application générique.
Les blocs d’objectifs ne se chevauchent jamais, même quand leurs ressources sont indépendantes : la durée totale est la somme des blocs, pas le chemin critique d’un ordonnancement fusionné.
Avec des corrections Event_Flow, la structure atteint trois niveaux : Nominal SubTask → bloc d’objectif → sous-processus de reprise. Les consommateurs doivent déplier les sous-tâches structurelles (getEffectiveTasks).
Le classement des fonctions repose sur la propriété pertinence (0–100) de Satisfies ; des valeurs égales ou absentes conservent l’ordre de découverte.
Une seconde NgZone liée à la zone de l’hôte lève NG0909 et le dialogue ne s’affiche jamais.
Le serveur sert le jar depuis son classpath : installer le module npm serveur arrêté (un jar écrasé sous une JVM en cours répond HTTP 500 « invalid LOC header »), puis forcer le rechargement de runtime.js et main.js dans le navigateur, qui les met en cache.
Seul le planificateur Default est pris en charge ; Choco et Cofiade restent désactivés dans le dialogue.
Module backend java/backend/gind-governance/gind-governance-workflow-deduction-strategy-native-basic-bloc-satisfaction, package fr.emac.gind.workflow.deduction.
NativeBasicBlocSatisfactionProcessGenerator.javaEntrée SPI de la stratégie.NativeBasicBlocSatisfactionStrategyDeductionCampaign.javaParamètres, combinaisons, classement natif, pipeline à quatre tâches, plafond de solutions, publication.NativeBasicBlocPlanner.javaOrdonnancement par objectif, enveloppe en sous-tâche, enchaînement séquentiel, câblage Event_Flow.gind-governance-workflow-planner-default/…/RioDefaultPlanner.javaAffectation des ressources, conversion ordonnancement → processus, reprises Exception_Flow.gind-governance-workflow-deduction-strategy-abstract/…/AbstractDeductionStrategy.javaRapports et indicateurs de campagne, getEffectiveTasks.gind-npm-strategy-deduction-native-basic-bloc-satisfaction/src/Entrée de l’extension, composant de dialogue, service, jeton des services de l’hôte.gind-webapp-generic-application-users/…/deduction-strategy-extensions.jsonScripts chargés par les applications hôtes.