Ideally, I would like a Query as solution.
Indeed, after having executed this Query, I need to create quickly associations, with a drag and drop of the set of instances got with the Query.
In any case, I must be able to create quickly the associations, with the set of Concepts retrieved.
According to me, and from a logical point of view, the syntax of the Query looks good.
- Step1 = selection of a set of Applications (compliant with some criteria) hosted in a City planning area (parameter) => set of Applications = @APP
Select [Application] Into @APP Where [Hosting Area] = &"CityPlanningArea" And [Application Type] = "In House Application" And ([Airbus - Application Type] = "Application Airbus" OR [Airbus - Application Type] = "Software Component")
- Step2 = selection of all the Concepts linked via the meta-association “Defined Object” with this set of Applications => set of Concepts = @Defined_BO
Select [Concept] Into @Defined_BO Where [Defined object]:[Application] In @APP
- Step3 = within @Defined_BO, selection of only the Concepts managed in “CRUD” mode by at least one of the Applications contained in @APP
Select [Concept] From @Defined_BO Where [Defined object]:[Application].([Airbus - Application Concept] = "CRUD" AND in @APP)
Note: In this step 3, the trick is the need to restrict the considered Applications to the set of Applications previously stored in @APP ; otherwise the result of the Query could be wrong in case of execution with all the Applications stored in the repository (i.e. the Applications not stored in @APP must be excluded from the query)
Example with 2 Applications, A and B:
- Application A is owned by the “ CityPlanningArea 1” ; it manages the Concept “C1” in CRUD mode = it is relevant for my Query
- Application B is owned by the “ CityPlanningArea 2” ; it also manages this same Concept “C1” in CRUD mode => when performing the Query for “ CityPlanningArea 1”, Application B is not relevant
