Reuse of previously profiled BIEs

[dubnemo]

Need the ability to reference a previously profiled component.

Ideally, while working in a BIE, user can right click on an aggregate component and reference a list of previously profiled BIE component AND its context based by its based on id, and associate that BIE at that level to the BIE in scope.

[kbserm]

Work around for now:

What you are asking for is what known in the realm of Core Component Specification as Document Assembly. This is a more complicated concept. Score has not implemented this yet. We had discussed and had idea about how this may be implemented. It will have to come after version 2.0.

As Jim said you can profile pretty much any OAGIS component. So the workaround at this time is to profile BODs, Verbs, and Nouns separately. For the BOD you would select/profile only the nodes you want up until the direct children of the Data Area (see figure below). You would then generate the schemas for the BOD, Verb and Noun you want to assemble. Then outside of Score, in a text/xml editor, you replace the empty Verb and Noun elements with the elements from the Verb and the Noun schemas that were generated earlier. You might want to make sure that the triplet of BOD, Verb and Noun you want to assemble together have the same business context or different business contexts that are overlapped (I haven’t thought much about the latter case, Elena and Nenad, also copied, have been thinking more about business context).

[kbserm]

• The top-level ASBIEP selection page should show Business Term and Remark columns.
• Biz_Term, Remark, Context Definition, Owner, Version and Business Contexts from the reused top-level ASBIEP should be shown on the Reused BIE node.
• User should still be able to customize the cardinality and add another (ASBIE) context definition.
• A any descendant ASBIE/ASBIEP/ABIE node of a top-level BIE, the user can create a top-level BIE of it. It will inherit business context from the top-level BIE.
• When a BIE node is reused, all descendant BIE entities need to be purged from the database.

[dubnemo]

@jwightma Can you have Joshua 'add his requirements for the record'? We can split off the EBOM, MBOM off to the polymorphic issue.

[joshklm]

Profile BIE for CC and Noun portion of BOD, and reuse the profiled entities in profiling other BIEs that incorporate those entities.

Core Component Profile Reuse Example: • Application Area

• Profile Application Area to be suitable for multiple business areas within the enterprise
• Example: Only enable Sender, Receiver and their subset of fields (e.g. Logical Id, Component Id, Id)
• When SCORE users within the enterprise profile other BOD types, their Application Area is already profiled, thus allowing the enterprise to maintain a consistent structure for the Application Area for all BIEs for all BOD types.

• Party

• Profile the Party core component to have only typeCode, Id, CAGEID fields to be utilized within the enterprise.
• When other users profile any other BIEs, they will be able to choose the already profiled Party, so the BIE will be consistent within the enterprise for the definition and fields used for the Party.

[kbserm]

Test Case 24.1 Reuse a BIE BIE reuse allows for top-level BIEs to be reused under another top-level BIE. Precondition: There are existing top-level BIEs in Production state that reference the same CC as a BIE under another top-level BIE being edited. There are also some other top-level BIEs in Production state that do not reference that same CC. Test Assertion:

1. For a particular descendant node (reuse-target node) of a top-level BIE in Editing state, the end user can invoke the ‘Reuse BIE’ function. 1.1. The reuse-target node can only be ASBIE/ASBIEP/ABIE node but not any BBIE/BBIEP nor SC node. The root top-level BIE node cannot be a reuse-target node. 1.2. Only ASBIEPs in Production state in the same Release as the top-level BIE that reference the same ASCCP as the target node can be chosen from. (Maybe from the UI the ‘reference the same ASCCP’ assertion can only be partially tested that only ASBIEPs with the same property terms are in the list) 1.3. An icon indicating a reused BIE shall be present. Clicking on that node shall open the corresponding top-level BIE in another tab. 1.4. On the detail pane of a reused BIE node, Business Term, Context Definition, Version, Owner, Business Contexts of the reused ASBIEP shall be display. The user can still customer cardinality, context definition, nillable details of the ASBIE (which belongs to the reusing top-level BIE). Details of the reused BIE and its descendant nodes cannot be changed.
2. The end user can reuse developer top-level BIE.
3. The end user can reuse a BIE that has a nested BIE Reuse. All reuse information shall appear appropriately on the UI.
4. The end user can remove the BIE Reuse. This menu option shall be available ONLY on the reused BIE node. After removal: 4.1. Only the ASBIE details remain on the detail pane of the node. 4.2. Other children nodes shall be unchecked. Test Case 24.2 Create a Top-level BIE from a BIE node This functionality allows the user to create a top-level BIE from a descendant BIE node within a top-level BIE. The created top-level BIE may be reused within another top-level BIE afterward. Test Assertion:
5. An end user opens a top-level BIE to view. The top-level BIE can be in any state and owned by anyone as long as it can be viewed by the end user. On any of the descendant ASBIEASBIEP/ABIE node that is not a reuse, the end user can invoke ‘Create top-level BIE’. Consequently: 1.1. A top-level BIE is created based on the content of the selected ASBIEP. It shall be a copy of that ASBIEP. 1.2. The newly created top-level BIE shall be in WIP state (after finish copying). 1.3. The top-level BIE is owned by the end user invoking the creation.

All here are test cases and assertions for BIE Reuse. This only includes assertions based on End User role. One different b/w end user role and developer role maybe that the developer cannot reuse end user BIEs.

Please comment on this.

[dubnemo]

@kbserm @joshklm @hakjuoh 24.1 -> 1.4 - didn't we suggest Remark be displayed? Also, is it easier to use a hover-tip to display Context Definition, Remark that could have significant amount of text? We may have 'real estate' challenges with this many fields. It should be stated that (perhaps 5) that all prior edited context descriptions, cardinality, etc., will be removed when Reusing a top-level BIE, perhaps a warning dialog issue if these existing -- there is no going back. Also state when 'removing' the BIE, that prior data will not be retained. This should force the user to check those reusable top-level BIEs in detail prior to selecting them.

24.2 -> 5 -> 1.1.1 Dialog box shall appear after copy, This can be an asynchronous delayed response callback that does not require user intervention. Perhaps we consider a 'notification' approach when users can check these notifications at future points in time, and there would be a notification 'tray' on the menu bar.

[joshklm]

24.1 - 1.2. Only ASBIEPs in Production state <-- Is this saying 'Published' state? Not sure Production state and Published state are the same meaning in Score. 24.1 - 2. The end user can reuse developer top-level BIE. <-- Looking at the note at the bottom as well, why is there restriction that developer cannot reuse end user BIEs?

24.2 - 1.1 It shall be a copy of that ASBIEP. <-- Does that mean the newly created copy contains the same meta data contents (version, remark, business context, etc) Will users be able to trace where the created copy originated from? End users may need to edit that info in the copy later, but starting the newly created one with the same meta data info copied by default would help tracing where it came from. (Likely because the originating top level BIE should be updated later when the newly create one is in Published state and the originating top level BIE reuse the newly created one for the node where it was created from.) 24.2 - 1.3 Are we going to test the newly created one getting published, and then being reused in other BIEs (including in the originating BIE)?

[kbserm]

@dubnemo I added Remark to 24.1 -> 1.4. But actually we talked about showing some details that includes Remark when selecting a top-level BIE for reuse. I have append to TA (test assertion) before 1.2 as follows "The pop-up dialog for choosing a top-level BIE must include the following details – State, Property Term, Business Term, Owner, Business Context, Remark, Version, Status, and Updated Date Time (Release is NOT needed, they must be in the same release as the reuse-target anyway). Filters shall be available for these columns. Business Context and Remark may be visible only when hovering over." I let Hakju decide about the UI. But Business Context and Remark are two columns that make sense for hover over b/c they may not be sortable (details are are shown only when hovering over are not sortable).

I have also added a 1.x TA stating "A confirmation dialog shall appear indicating that “Details of descendant BIEs will be lost. Do you want to continue?”

Your comment about about 24.2 -> 5. BIE being copied will appear in the BIE List page as in the Initialization state. When the copying is done and the user refreshes the page, he will see that it is in WIP state. At this time we don't have notification infrastructure yet esp. in 1.x. Hakju was going to do that in 2.0 but I told him to do it later. It will take longer to do implementation to have notification, let's do that later.

@joshklm Publish and Production are equivalent. Production is a 2.0 term. You are right, in 1.x, you will see it as Published. I use 2.0 terminology and made note in the Word Doc for @asdimitriadis to make sure that test scripts are adapted to 1.x appropriately.

Regarding your question on 24.1 - 2. By definition, developer is the standard developer. Standard developer shouldn't use artifact (randomly) created by the end user. Just like Core Component, standard developer cannot and should not use end user CC.

Regarding your question on 24.2 - 1.1. Yes, the newly created top-level BIE will have the same meta-data. There will be no physical link b/w new and the original. Since the new top-level BIE will be in WIP (Editing) state initially, top-level BIE details can still be changed. Note that non-top-level BIE does not have version, so the version field of the newly created top-level BIE will initially be blank.

Note that we can do this differently also. That is, if we want to force/assume the user to make sure that original BIE is in good shape before invoking "Create a top-level BIE from a BIE node", then we can make the new top-level BIE in Published state right away and change the original BIE node to be a reuse right away. In this case the process will be much faster and we don't need asynchronous copying. Basically, the original BIE node will be simply altered to become a top-level BIE. We can give the user an opportunity to add & edit some meta-data before the alternation. Do we want to go this route?

Regarding your question 24.2 - 1.3. If the top-level BIE is successfully created. I think we can assume that its reuse is good based on Test Case 24.1. I don't see this as a necessary boundary condition to test.

[joshklm]

@kbserm Regarding 'Note that we can do this differently also', I can see pros and cons in either approaches. Best thing would be to give options for users, but I don't like keep increasing the scope on this. So, until the options are provided for the user to pick, it would make sense to create a copy in WIP state, and let users to do the rest of the work (asynchronously) rather than making it automatic and stick published (production) state automatically - where the user will be stuck without flexibility to further refine the reuse BIE that is newly created.

[kbserm]

I think we can do both options.

[kbserm]

@rekuku new entries in OAGIS Terminology should be needed for new menu items and some new labels on UI related to this functionality. Could you propose OAGIS terminology for those based on existing ones?