JaewookByun / epcis

Oliot EPCIS for GS1 EPCIS/CBV 2.0.0
http://dfpl.sejong.ac.kr/epcis/home/index.html
Apache License 2.0
46 stars 55 forks source link

Error parsing /capture data in "TagDataTranslationEngine.toInstanceLevelEPC" #82

Closed Siko91 closed 1 year ago

Siko91 commented 1 year ago

Hello again.

I have now started working on using the API of this server. I attempted to call the /capture endpoint with some testing data. (I will provide that testing data bellow.) However the EPCIS document I passed seems to be rejected.

I am not completely sure that my test data is actually correctly formatted, but after examining the code, I believe that it is... or at least that if there is a problem, it is somewhere else and not where the code fails.

The code fails in this method: TagDataTranslationEngine.toInstanceLevelEPC() In it there are 3 parts of the code:

  1. determine a variable IdentifierType type by attempting to parse the parameter as a Digital Link
  2. depending on the determined type, go into one out of a series of if statements and properly parse the actual string
    • Inside most of these parsing function, the code will attempt to parse the string as a Digital Link
    • If it fails, it will then attempt to parse it as some sort of EPC URN (urn:epc:id:<some-type>:<some-numbers>)
  3. if the type doesn't match any of the if statements, an error is thrown.
    • Unsupported instance level code scheme
    • This is the exact error I see when I pass my event to /capture

To reproduce my problem, simply run this code snippet: TagDataTranslationEngine.toInstanceLevelEPC("urn:epc:id:sgtin:4023333.000055.1A")


Alternatively, you can call the /capture endpoint with this JSON data: {"@context":["https://ref.gs1.org/standards/epcis/2.0.0/epcis-context.jsonld"],"type":"EPCISDocument","schemaVersion":"2.0","creationDate":"2021-05-25T08:33:43.015Z","epcisBody":{"eventList":[{"type":"ObjectEvent","@context":[],"eventTime":"2021-05-25T08:33:43.015Z","eventTimeZoneOffset":"+02:00","epcList":["urn:epc:id:sgtin:4023333.000055.1A","urn:epc:id:sgtin:4023333.000055.1B"],"action":"ADD","bizStep":"commissioning","disposition":"active","readPoint":{"id":"urn:epc:id:sgln:4023333.00002.0"},"bizTransactionList":[{"type":"po","bizTransaction":"urn:epc:id:gdti:0614141.00002.123"}]}]}}


So what does actually happen?

  1. In step 1 the code tries to get the Digital Link type of "urn:epc:id:sgtin:4023333.000055.1A" and it fails, because it is not a digital link.
  2. The correct type should have been IdentifierType.SGTIN.
  3. If the type was actually set to IdentifierType.SGTIN, then SerializedGlobalTradeItemNumber.toEPC(instanceLevelDL); would have been called.
  4. in the toEPC method the getDigitalLinkMatcher would have failed, as the string is not a digital link.
  5. but the next part (getElectronicProductCodeMatcher) would have succeeded, because one of the EPCPatterns.SGTINList regex patterns actually matches that string.
  6. That matching regex pattern is my reason to beliefe that my test data is actually in the correct format.
  7. however since the type variable was null, the code moves to the last part instead, where it throws an error.

This problem seems to be present in some other methods inside of the TagDataTranslationEngine class.

However the solution seems to already be implemented in another method: TagDataTranslationEngine.toEPC


Best regards, Aleksandar Dinkov

JaewookByun commented 1 year ago

Hi again,

I appreciate your contribution on docker. My researcher reported me that it works nicely! Regarding the report, I have to disclose these: 1) I recently started implementing EPCIS again toward 100% compliance of the standard. 2) Regarding XML and SOAP, I believe it closes. 3) I am now implementing JSON capture part again. ( it works fine in v2.1.0 but not fully compliance to the standard )

In our implementation, XML/SOAP receives and deliver XML with EPC Pure Identity (e.g., urn:epc:id:sgtin:4023333.000055.1A) and JSON/REST will receive and deliver JSON with GS1 DL. (e.g., https://id.gs1.org/01/04023333000550/21/1A)

What I mean is that 'TagDataTranslationEngine.toInstanceLevelEPC' is implemented as I intended.

I recommend the following. (Actually, I don't know what is your purpose of using Oliot EPCIS though.)(Could you introduce yourself if you have a willing to?) 1) use XML/SOAP interface

See our WIKI page

2) or use /events interface, namely single event capture. The following invocation works well because I just tested it.

HTTP.POST /epcis/events

3) to convert GS1 DL to EPC pure identity You can invoke our draft version of TDT engine as follows.

HTTP.GET /tdt request header Content-Type : application/json request body

{
    "id" : "urn:epc:id:gdti:0614141.00002.123"
}

Then you will get the following

{
    "epc": "urn:epc:id:gdti:0614141.00002.123",
    "dl": "https://id.gs1.org/253/0614141000029123",
    "companyPrefix": "0614141",
    "documentType": "00002",
    "checkDigit": "9",
    "serial": "123",
    "isLicensedCompanyPrefix": true,
    "granularity": "instance",
    "type": "GDTI"
}

Thank you for being interested in our project.

Best regards, Jack

Siko91 commented 1 year ago

Thank you for explaining. I am still extremely new to EPCIS, which is why I didn't know about the /events endpoint at all.

So... is the preference for Digital Links over URNs something that all EPCIS servers lean towards, or is it specific to this implementation?

The /tdt endpoit appears to be very useful. Thank you for telling me about it. I'll probably take the code behind it and convert it to a single function in order to avoid unnecessary communication with the server.

My current purpose is to develop a reliable EPCIS client library in JS (or multiple libraries in different languages if that becomes necessary) which would be used by a company I work for in order to develop products that can work alongside with EPCIS servers. I have chosen to test this library against your server, as it appeared to be the most actively developed one (out of the OSS options). Later I will also test the client library against FasTnT-EPCIS, which also seems to support EPCIS v2.0.0. I wish to make a library that is independent of the specific server implementation. The next step after making the library would be to create a generic web frontend for managing an EPCIS server (mostly intended for admins, not for regular users). This too will help a lot with developing the actual products of the company.

Basically - in the next few days I will be using the server actively and writing a lot of test scripts.

P.S. : Do you happen to know where I can get a good dataset of EPCIS events which can be used to fill the database with structured consistent data? I wish to have something like that when writing the Query part of the library, in order to see realistic looking responses to my queries. The post important property of such a data set would be for the latter events to properly reference actual existing items, instead of using some random IDs that were never mentioned before.

P.S. 2 : If you happen to have a good opinion of any existing client library for EPCIS 2 (regardless of language), please recommend it. If it is OSS, I will likely inspect how it is written and translate the parts I need to the languages I need them (probably JS & C#) Sadly, the existing libraries written in JavaScript (that I have seen) appear to be lacking.

JaewookByun commented 1 year ago

Thank you for explaining. I am still extremely new to EPCIS, which is why I didn't know about the /events endpoint at all.

So... is the preference for Digital Links over URNs something that all EPCIS servers lean towards, or is it specific to this implementation?

The /tdt endpoit appears to be very useful. Thank you for telling me about it. I'll probably take the code behind it and convert it to a single function in order to avoid unnecessary communication with the server.

My current purpose is to develop a reliable EPCIS client library in JS (or multiple libraries in different languages if that becomes necessary) which would be used by a company I work for in order to develop products that can work alongside with EPCIS servers. I have chosen to test this library against your server, as it appeared to be the most actively developed one (out of the OSS options). Later I will also test the client library against FasTnT-EPCIS, which also seems to support EPCIS v2.0.0. I wish to make a library that is independent of the specific server implementation. The next step after making the library would be to create a generic web frontend for managing an EPCIS server (mostly intended for admins, not for regular users). This too will help a lot with developing the actual products of the company.

Basically - in the next few days I will be using the server actively and writing a lot of test scripts.

P.S. : Do you happen to know where I can get a good dataset of EPCIS events which can be used to fill the database with structured consistent data? I wish to have something like that when writing the Query part of the library, in order to see realistic looking responses to my queries. The post important property of such a data set would be for the latter events to properly reference actual existing items, instead of using some random IDs that were never mentioned before.

P.S. 2 : If you happen to have a good opinion of any existing client library for EPCIS 2 (regardless of language), please recommend it. If it is OSS, I will likely inspect how it is written and translate the parts I need to the languages I need them (probably JS & C#) Sadly, the existing libraries written in JavaScript (that I have seen) appear to be lacking.

Hi

Here are my answers on your questions: Q1) So... is the preference for Digital Links over URNs something that all EPCIS servers lean towards, or is it specific to this implementation?

Desirably, EPCIS systems support both identifier schemes, and during the development of GS1 EPCIS 2.0.0, the standard guides to use EPC Pure Identity on XML-formatted EPCIS documents and GS1 Digital Link on JSON-formatted EPCIS documents. Actually, it is up to how to implement EPCIS systems but there is a way for users to know how any implementation receives a specific type of id schemes. The hint is on a response header called GS1-EPC-Format on HTTP.OPTION ( one of No_Preference, Always_Digital_Link, Always_EPC_URN, Never_Translates ) The point is 1) Oliot EPCIS supports both schemes. 2) JSON/REST handle GS1 DL and XML/SOAP handle EPC Pure Identity. 3) while REST can filter and receive EPCIS events captured as JSON and vice versa.

A2) Privately, we have our EPCIS client written in Java and a Web client.

A3) Regarding event/vocabulary templates, please check #7 in our Wiki page. It will be updated continuously.

Thank you

Best regards, Jack

Siko91 commented 1 year ago

I forgot to close the issue. Closing it now :)

Siko91 commented 1 year ago

Oh. One more thing. In the wiki (page 7) you listed example 14 twice in a row.

JaewookByun commented 1 year ago

Oh. One more thing. In the wiki (page 7) you listed example 14 twice in a row.

Wow. Thanks a lot. The lengthy statements let me paste twice.