Way/workaround to take over a parentID to subsequent event(s)

[RalphTro]

Dear @Aravinda93 ,

When I tried to create an event sequence with an AggregationEvent (where SGTINs are aggregated to an SSCC (bizStep packing)) followed by an ObjectEvent (with the SSCC, bizStep shipping) I was only able to take over the child elements (i.e. SGTINs), but not the parentID (SSCC).

Do you see a way how users could take on the SSCC for subsequent events (where the same SSCC appears in the receiving and unpacking event)?

Looking forward to hearing your thoughts.

As a first spontaneous idea : what is your take on introducing e.g. a button through which users could copy such an SSCC to the clipboard for subsequent events? I think that such w workaround would not be too much work/impact the current software logic, but very helpful. You may come up with a more elegant idea though... :-)

Kind regards, @RalphTro

[Aravinda93]

Dear @RalphTro ,

Thanks for bringing this to notice. As per I remember the if AggregationEvent is used with parentID and next ObjectEvent then it would not consider the parentID because the ObjectEvent does not support parentID. However if suppose AssociationEvent or another AggregationEvent is used instead of ObjectEvent then it can take the parentID from previous Association/Aggregation Event. I will look into the code again to confirm this.

If parentID needs to be considered during the subsequent ObjectEvent then should it go as a part of epcList?

With regards to the Button for copying parentID: Sure, I will look into this because there can be large data I am not storing as a part of JavaScript so I may need to figure out how to obtain them back from NodeJS without impacting the application performance. I will play around based on the mentioned scenario to see if I can come up with some idea that can be helpful. If something clicks then I will post here again so you can confirm if we can take that route.

With regards to other 2 issues: issue1 and issue2 I will start only after your confirmation.

Thanks and Best regards, Aravinda Baliga B

[RalphTro]

Excellent, @Aravinda93! Turning to your question: in practice, it is not uncommon that a 'Shipping' ObjectEvent follows a 'Packing' AggregationEvent. In such cases, having the option to take over the parentID (e.g. an SSCC) from the previous event into the shipping event would be convenient.

I am also aware of other scenarios how this is modelled in practice (e.g., there are companies which model their shipping events as an AggregationEvent with action=OBSERVE which accommodates both the parentID and the contained child elements) - but also in such a scenario this enhancement would be helpful.

Thanks in advance for looking into this!

[Aravinda93]

Dear @RalphTro ,

I have added the logic to capture the parentID from the previous event if exists. If the previous event consists of the parentID then the current event would inherit them as EPCs. So the AggregationEvent parentIDs are inherited by the subsequent ObjectEvent as part of EPCs.

Based on this I have created the Example events for the scenario mentioned in the Google Doc. All these new codes and examples are present within **fixes** branch of this GitHub Project. Please check them out and let me know if everything is as you expected them to be.

Thanks and Best regards, Aravinda Baliga

[RalphTro]

Dear @Aravinda93 , Thanks a lot! I just did some first testing (with the fixes branch) and am happy to share my observations:

Here is what I wanted to create: a set of (respectively) an Aggregation Event where SGTINs are aggregated to an SSCC, followed by an Object Event where the epcList is only populated by the SSCCs. Here is the screenshot of my configuration:

As you can see, the epcList now includes a mix of the SSCC and SGTINs which were previously aggregated to this SSCC, FYC:

`

https://id.gs1.org/01/04012345123456/21/pPoTpPBZu

      <epc>https://id.gs1.org/00/340123454899661830</epc>
    </epcList>

`

This is also the case in the sample files you created. However, this is not how practitioners would require it: they will expect that in e.g. a shipping event which follows a packing event, only the parent IDs (i.e. in this example, the SSCC) appear in the epcList.

Here is what I think could be a way out to address this need: what is your take on enhancing the connector logic so that, in addition to the number of EPC and quantity identifiers which should be passed on to the connected event, users can also indicate the number of parentID(s) that need to be passed on?

This way, the tool should IMHO cover all related use cases: (a) a sequence of events where both parentID and childIDs must be passed on (which is the case where the second event is e.g. an Aggregation event with action OBSERVE, (b) a sequence of events where only the parentID is passed on (useful e.g. when passing it on to unpacking events, i.e. Aggregation Events with action DELETE) (c) a sequence of events where several parentIDs need to appear in the subsequent ObjectEvent (think of 100 Packing Events followed by 5 shipping events, where each Shipping Event accommodates 20 SSCCs)

I think the current logic as implemented (indicate the number of EPC/quantity identifiers) is already fine for all other cases (i.e. epcList, quantityList, outputEPCList, outputQuantityList, childEPCs, childQuantityList). But if we want our tool to also empower users to unambiguously indicate parent-child-relationships, IMHO, this enhancement would make a lot of sense.

What is your take on this suggestion? (Of course, as parentID can also appear in Association/Transaction Events, the solution approach must also applied similarly for them. If you think it helps, we can also focus on AGgregatinEVents for the time being before you modify the source code for the other two event types.)

Looking forward to hearing your thoughts/feedback.

BTW: also for validation/testing purposes, I am happy to create the healthcare-related messages for our article. So, don't bother about the next iteration of the sample files.

Kind regards, @RalphTro

[Aravinda93]

Dear @RalphTro

Thanks a lot for the explanation on the parentIDs. Sure, similar to epcList and quantityList, I will provide an option in the frontend to pass on the parentID. Based on the provided values I will build the logic to create the events with appropriate epcs in subsequent events.

I was actually planning to modify the logic to pass only SSCC to ObjectEvent but since other logic was already built I thought it may be correct so I continued with it. Anyways I will make appropriate changes so that the subsequent event only takes the parentID based on user-provided values from previous events. After completing the changes I will update you so you can test these changes.

Thanks and Best regards, Aravinda

[RalphTro]

Dear @Aravinda93 , wonderful! Thanks in advance for building in this enhancement so that the three above-mentioned cases (a/b/c) are working... BTW: if you think it makes sense to have a bilateral call to speed up things, please just drop me a line! Kind regards, Ralph

[Aravinda93]

Dear @RalphTro

Thanks a lot for offering the call, Actually I was able to understand these changes based on your previous comment. However, in future If I am stuck in any issue and require more clarification then I would definitely request for the call.

Based on your suggestion, I have made the appropriate changes to the code and briefly tested with few scenarios. Now, I believe it should work for all above mentioned scenarios.

I have created a sample events after the changes and placed it in the Example Events folder of the fixes branch. Please test from your side and let me know if everything is working as expected. I would be happy to make any changes if you need any further enhancements.

Have a great evening ahead :)

Thanks and Best regards, Aravinda

[RalphTro]

Dear @Aravinda93 , Thanks for this - you are really fast! 👍 I just made some quick tests (covering all three cases I outlined earlier) and all looked fine to me. Well done! Kind regards, @RalphTro