/
BIE Uplift

BIE Uplift

Owned by Serm Kulvatunyou
Last updated: 2021-01-05
3 min read

BIE uplift is about transferring BIEs that are based on the previous release of CCs to a newer release of CCs.

*Note that we decided to use the word uplift instead of upgrade to make it easier to distinguish from Score software upgrade.

https://docs.google.com/presentation/d/1tDn3ibjF9R3rSoPAZ1e6a6J3A9guyPZtGVNOb3qp_ps/edit?usp=sharing

Extension Copying

Extension copying means copying the underlying User Extension Group ACC (UEGACC - this is the ACC that encapsulates the added properties). This has to be copied first before info of BIE nodes in the extension can be copied.

  1. What to copy? Here are possibilities.

    1. Copy all the properties regardless of whether they are used in the BIE being uplifted. 

    2. Copy only properties used in the BIE being uplifted.

    3. Copy properties used across all BIEs that share the same UEGACC and then can never be copied again when other BIEs are uplifted.

  2. In 1b, when another BIE that share the same UEGACC is uplifted, things will be getting more complicated because another user might be changing that UEGACC, i.e., it is in WIP or QA state and it might have duplicate components so the application would have to carefully merge the properties. Regarding the state, the safe state to merge is WIP and ownership got transferred to the user doing the uplifting.  So option 1a and 1c are more viable.

  3. In future versions of Score, any End User CCs (EUCCs) used in the UEGACC have to be copied as well. This may not be very undesirable b/c they may not be needed in the new release.

  4. It should be noted that after the first time UEGACC is copied/created, it will have to be put in Production state and Rev 1 in order that the corresponding BIE nodes can be copied. Once UEGACC is in Production state with Rev 1 and some BIE referencing it, only backwardly compatible changes can be made in future amendments (revisions).

  5. So in my view blindly copying UEGACC and EUCCs into the new release kinda pollutes the new release.

Another motivation for Scott to keep the extension is some service client may not uptake the changes yet so the service might need to carry the information both in the extension and the new components/fields.

Now that Scott is ok with not copying the UEGACC. Here are some thoughts about MVP on the matching UI.

Thoughts about MVP of this functionality

  • Let the user match the unmatched nodes manually.

  • Generate a report at the end for nodes that the user didn’t match. The report includes path of the node and its BIE details.

  • Allow using to match only when the nodes are of the same type, i.e., ASBIE/ASBIEP/ABIE node with ASBIE/ASBIEP/ABIE node, BBIE node with BBIE node, and BBIE_SC node with BBIE_SC node. The system The system doesn’t have to check compatibility in this version. However, there will be cases where some BIE data cannot be copied. These would be when the BIE detail field is a value list. The system can just throw an exception when the value in the source does not exist in the corresponding value list in the target. Maybe the system only copy the BIE details of all nodes in the next step. If some BIE details of a particular node cannot be copied, then that node is skipped and the node is output in the report as unmatched.

  • Maybe the report also output the path of the succeeded manually matched & copied nodes.

 

https://oagi.org/pages/connect-membership