/
BIE Reuse

BIE Reuse

Owned by Serm Kulvatunyou
Last updated: 2021-01-14
4 min read

Score Issue #1010 about requiring BIE to be published to be reusable.

  1. https://github.com/OAGi/Score/issues/1010

  2. Josh is okay that BIE in WIP state can only be reused by BIEs with the same owner.

  3. Josh is okay that state of the reusing BIE cannot be more advance than state of the reused BIEs.

  4. This issue is related to the ability to make some changes to or delete published BIE based on a more sophisticated role-based access. This issue might solve this problem.

  5. Some thoughts

    1. Change how the feature is used.

      1. Because of #2, why would the owner makes the BIE reusable right away. It would be a better process if he keeps the BIE node destined to be reusable BIE local until he is confident that it is in stable state.

    2. Does this more detail user story reflects the situation and the problems?

      1. User A makes Show BOM BIE. He would like the BOM BIE node of the Show BOM BIE to be reusable in other BIEs like Process BOM BIE and Acknowledge BOM BIE. These two other BIEs are concurrently managed by user B.

      2. While user A is testing on the Show BOM, user B also would like to have his Process BOM BIE tested and he wants his BOM BIE node to be the same as that in the Show BOM BIE.

      3. Problems:

        1. If user A makes his BOM node a reusable BIE, it is not reusable until the BOM BIE is in production.

        2. If BOM BIE is in production, and changes are not possible when needed after testing. While user A may be able to change his BOM BIE node and recreate another version of the BOM BIE to be reused in other BIEs, the current limitation can cause a garbage BIEs. Because unwanted reusable/top-level BIE cannot be deleted in production state.

      4. Possible solutions:

        1. Assume the BOM node of the Show BOM BIE does not reuse the BOM BIE yet. That means user A can make changes to his BOM BIE node (after testings) and create a recreate a reusable BOM BIE again. If we allow published BIE to be deleted by a certain user, this might solve the problem? Josh also proposed that some changes to the BIE meta-data is allowed even after it is in production. Which one is better or we need both?

        2. Allowed BIE reused when it is in QA or even in WIP. This approach may make life-cycle of BIEs convoluted. Complex business rules may be needed as documented in the issue. However, we could opt to make BIE state dependency independent like CCs. But the problem is, in CC, there is a release management which is when states of all relevant CCs are brought inline.

  6. Allowing the notion of BIE deletion.

    1. We might want to implement something like CC management. That is, adding another one or two states to the BIE.

      1. “Deleted” just means mark deleted. It can be restored by another user. It can be purged at some point by another (more powerful) user. In this way, referential integrity does not have to be checked often; it only need to be checked when purging. Unlike CC, BIE deleted state is allowed after it is in Production. We should note that BIE can be discarded in WIP state (basically until it becomes production, it can be discarded).

      2. “Deprecated”. We can also allow BIE to be deprecated after it is in Production.

      3. Top-level BIE may be flagged if there is any deprecated or deleted reused BIE node. Or may be a warning is simply gave when expressing the top-level BIE, as the former may be a little expensive if the BIE is big.

  7. Allow BIE reused when not in production

    1. In this case, we would want to make BIE life-cycle states independent like CCs. But still retain the constraint that once in Production cannot go back. In place of release management, we can flag the top-level BIE if it has any reused BIE that is lag in its state. But again, this flagging may be computationally expensive (BIE is slow to open) if the BIE is big.

      1. Josh thinks that letting anybody reusing BIE not in production state is too complicated. He thinks that allow only owner to reuse non-production BIE is good enough. This with #6 seems to be ideal. Allowing anybody to reuse non-production BIE other than the owner could become convoluted b/c unlike CC where there is a release check point to bring everything under the same state. BIEs evolve rather independently.

  8. It might be best to do both #6 and #7. But perhaps do #6 first is sufficient?

 

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