-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Future of this project #24
Comments
I think there is a need for a solid EDI Parser/Generator in JS. node-x12 is by far the best out there and I for one am very appreciative you kept it going but it's got some dust on it just due to being old. I think you have made a great case for creating a totally new project instead of making major changes to this one. My opinion would be to just retire this project once js-edi is stable. I can't really contribute to requested features yet because my app using node-x12 is still in development (🤞 we go live in a few months). Once we are live I will be more than happy to give better feedback. |
@ahuggins-nhs Thanks for letting us know. This all makes total sense, and I'm excited to see js-edi take shape (will start following the repo!). I really appreciate your work maintaining and expanding this library up until now and your investment in open tooling for X12/EDI in general. Please let me know (through issues or discussion on the js-edi repo?) if there are particular contributions that would be helpful at this point. |
Regarding your questions -- for our use, I ended up writing a layer around node-x12 that provides named access to elements in the EDI message. Basically, you can do things like this (pseudoCode):
It's written with Proxies, so while it looks like dot-notation, behind the scenes it's just JSEDI notation with smart getters (and setters, for updating/building the message -- but I only have a couple of those in place). The current implementation is crufty, especially when it comes to components (within elements) and hard-coded to the transactions that we typically use, but I wonder whether a tool like this might be helpful as part of JS-EDI -- maybe not core but as part of the suite. Since we can't distribute the schemas with OSS, ideally we'd be able to offer a CLI to convert the schemas from X12/WPC into a format that could be loaded by the library. I'm curious if others would find something like this helpful. The part of node-x12 that I depend on the most is serialization of an X12 Object / JSEDI into a valid message with all of the delimiters, control numbers, and segment counts in place, and would hope that similar functionality makes it into js-edi. |
Great work, @ahuggins-nhs! I never really anticipated node-x12 being useful outside of TrueCommerce as it was hastily written to support an internal VS Code extension. I'm happy to see it was given a second life! Best of luck with js-edi! |
@boxfoot I like the idea of providing similar functionality to the dot-notation/named property style. I've used Proxy class similarly in an unrelated project https://github.com/aaronhuggins/kodi-api/blob/main/lib/KodiClient.ts. Given the validator that I recently finished (I think it's finished) that can validate an EDI document that has been parsed using JSON Schema, I think we could probably tie that with a given JSON Schema or interface that the proxy could use to access the underlying DOM. What would be REALLY powerful, is if we could provide a |
Is it worth it to have some level of compatibility with this library to make transition to |
I think a clean break would be better, in my project I abstracted the use of node-x12 away enough to easily support changing it out. |
@ahuggins-nhs Thanks for your contributions to this project and very excited to see the transition to js-edi. We went live in production with this few weeks back and so far it is very solid. Our use-case is primarily dealing with parsing EDI214s and normalizing the data to our application data model. I've dived in the world of EDI recently so take the feedback from that perspective:
export const EDIx12Map: IEDIX12Map = {
ST: {
// Transaction Set Header
edi_type_code: 'ST01',
edi_control_number: 'ST02'
},
B2: {
// Beginning Segment for Shipment Information Transaction
traffic_service_code: 'B201',
carrier_scac: 'B202',
standard_point_location_code: 'B203',
shipment_id: 'B204',
weight_unit_code: 'B205',
payment_terms_code: 'B206'
},
B2A: {
// Set purposes
transaction_set_purpose_code: 'B2A01',
application_code: 'B2A02'
},
NTE: {
// Note/Special Instructions
note_reference_code: 'NTE01',
free_form_description: 'NTE02'
},
B10: {
// Beginning Segment for Transportation Carrier Shipment Status Message
carrier_load_id: 'B1001', // Carrier PRO # or invoice number
client_load_id: 'B1002', // the shipper's master BOL number
carrier_scac: 'B1003', // : Standard Carrier Alpha Code (SCAC)
inquiry_request_number: 'B1004',
reference_id_qualifier: 'B1005',
reference_id: 'B1006',
response_condition: 'B1007'
},
L11_72: {
// Business Instructions and Reference Number
reference_id: 'L1101:L1102["72"]', //L11 has qualifiers
reference_id_qualifer: 'L1102:L1102["72"]',
description: 'L1103:L1102["72"]'
},
L11_QN: {
reference_id: 'L1101:L1102["QN"]', //L11 has qualifiers
reference_id_qualifer: 'L1102:L1102["QN"]',
description: 'L1103:L1102["QN"]'
},
L11_BM: {
reference_id: 'L1101:L1102["BM"]', //L11 has qualifiers
reference_id_qualifer: 'L1102:L1102["BM"]',
description: 'L1103:L1102["BM"]'
},
...
///extends another 150 lines
...
SPO: {
//Shipment Purchase Order Detail
purchase_order_number: 'SPO01',
reference_id: 'SPO02',
unit_measurement_code: 'SPO03',
quanity: 'SPO04',
weight_unit_code: 'SPO05',
weight: 'SPO06',
application_error_condition_code: 'SPO07'
},
SE: {
// Transaction Set Trailer
number_of_included_segments: 'SE01',
set_control_number: 'SE02'
}
}
I'm happy to provide more feedback if needed. But thanks so much for this library, you don't realize how much this has helped us out. |
@ahuggins-nhs this is awesome. I am an EDI developer and a full stack engineer . i would love to contribute the best way i can. |
Hey all, I'm going to be giving this some maintenance over the next month. Among the things I'll be doing:
Overall, this change should make it easier for me to maintain this library going forward, so it's less time doing "npm install... dammit, vulnerability, why... oh, it's a Node quirk..." and more time doing "Blissfully making my code run correctly on either Node or Deno". See #37 |
Also, if anyone knows anyone who's hiring, I'm open to work. Especially if folks want to hire me to work on EDI parsing/handling. |
@aaronhuggins how are you doing? I am thinking we could collaborate on a project which could be an MVP. Let me know if you are interested. I would love to work with you. |
Hey @dejavxtrem. I was not doing great a few months ago, very sick for quite a while and only recently better. Trying to find work again and being picky about staying primarily Node/Deno focused. My DMs are open to mutuals on Twitter, so if you @ aaronhugginsdev there we can talk. |
@aaronhuggins i am not on twitter. but we can connect via email: dejavxtrem @ hotmail.com . Send me an email when you can |
This EDI X12 library is going to enter maintenance mode. This is for multiple reasons which I'll lay out below. The good news: this will remain in maintenance mode until either
js-edi
hits a stable version 1.0.0 (more on that later) or the community wishes to carry this library forward.The reasons I'm not happy with the current state of this library (which is STILL great, thanks TrueCommerce and @DotJoshJohnson, this is still the superior JavaScript library for ASC X12):
It's not that any of this is unmaintainable or wrong (well maybe in a few cases). There just are optimizations that I would like to make and features I think should be a part of handling or parsing EDI that are difficult to add with the current state of the code. Just a few things I want:
Given all of this, I started on an experimental parser written in ANTLR4 grammar. Once I had the parser fully functional, I added an (unfinished) EDIFACT parser in ANTLR4 grammar as well. Then, I reimplemented an object model, and rewrote the element selector language in ANTLR4 and...
Now I'm getting somewhere with the project that I'm calling
js-edi
. The parser appears to be faster, supports more features of EDI X12, and seems very flexible. The element selector implementation (in progress) is blazing fast. Everything is in a state of flux (especially documentation) since the library is immature, but I'm at a point where I would really appreciate community feedback and community contributions, as well.node-x12
?It's been awesome to have been able to maintain, enhance, and add features for the last 2 years with the community for this library. Thanks again to @fpw23 @DotJoshJohnson @boxfoot and other contributors and users. I look forward to discussion on this issue.
The text was updated successfully, but these errors were encountered: