ballerina-platform / edi-tools Goto Github PK

Description:
$subject

Suggested Labels:

Suggested Assignees:

Affected Product Version:
ballerina 2201.8.2

OS, DB, other environment details and versions:

Steps to reproduce:
When following the https://ballerina.io/learn/edi-tool/#code-generation-example and executing the following command by passing the wrong path for the schema file path, it runs without any error. But didn't generate the source.

bal edi codegen -s resources/edi-schema.json -o modules/hmartOrder/orderRecords.bal

Related Issues:

Description:
This module is a great start to parse EDI files and get them as a standard JSON format that's way easier to do work with. However, there's still a lot of work to be done when it comes to integrating EDI files with a larger ecosystem. I feel it'll be great if we can incorporate and provide a way to encapsulate information in implementation guides here as well for specific EDI types.

For example, EDI 834 Benefit Enrollment files, when parsed we get a JSON and there are segments like this,

            "A_2100_Loop": [
                {
                    "Individual_or_Organizational_Name": {
                        "code": "NM1",
                        "Entity_Identifier_Code": "IL",
                        "Entity_Type_Qualifier": "1",
                        "Name_Last_or_Organization_Name": "SMITH",
                        "Name_First": "WILLIAM",
                        "Identification_Code_Qualifier": "ZZ",
                        "Identification_Code": "202443307"
                    },
                    "Employment_Class": [],
                    "Monetary_Amount_Information_2": [],
                    "Health_Care_Information_Codes": [],
                    "Language_Use": []
                }
            ],

Based on the implementation guides, A_2100_Loop correspond to Member Name. The Entity_Identifier_code value IL here indicate that member's first name, middle name and last name has not changed since the last time there's been a update. One will not be able to get this information just by looking at the parsed JSON.

If there's a way for us to capture and present this information, then I think it's going to make life easy for a lot of developers who will start using this module.

One way would be, to change descriptive names. However, if we just use descriptive names then it'll be a bit hard for someone to refer to the implementation guide and make sense of it. Once parse, or when parsing maybe we can introduce another method like "fromEdiString" that will give a much more distilled, user readable message encapsulating info in the implementation guide. Something like,

    "MemberInfo": [{
        "FirstName": "WILLIAM",
        "MiddleName": "",
        "LastName": "SMITH",
        "Type": "Person",
         ... 
    }]

So we can get a 1:1 JSON representation of an EDI message as well as a "parsed" or "computed" message with code values translated into human readable form.