While traversing the document, elements cant be found using find method or element method

[ghost]

I tried traversing a HB271 document but it doesn't generate expected results. Can you just give a small demo as in how to traverse a document. I tried it multiple times with failure.
I tried positioning the cursor at first and could find ISA and GS segment, but nothing from there after and received message saying that segment is unreachable from current state.

[kputnam]

Hi,

There's a demo at the end of README.md and more documentation is available in Navigating.md. There's also a few test files for HB-271 in the spec/fixtures directory.

require "stupidedi"

path   = Dir["spec/fixtures/*HB*/*good.txt"].first
config = Stupidedi::Config.default
parser = Stupidedi::Builder::StateMachine.build(config)
input  = File.open(path, encoding: "ISO-8859-1")

# Parser is a state machine positioned at the end of input
parser, result = parser.read(Stupidedi::Reader.build(input))

If you're able to navigate to the GS segment, you should be able to then navigate to the child ST segment, unless your document is malformed or wasn't parsed. Turns out that's the problem, skip to the end of this comment to see. The two errors you'd expect to see are:

>> parser.first.flatmap{|x| x.find(:ST) }
=> Stupidedi::Exceptions::ParseError: ST segment cannot be reached from the current state

It's a runtime exception that means you attempted to move from one state to another state (in this case from ISA ST) but there is no legal transition between them. You must first transition to GS, then to ST: parser.first.flatmap{|x| x.find(:GS) }.flatmap{|x| x.find(:ST) } or see sequence for a more concise method.

The other error is not an exception, it just means your query didn't turn up any data. For instance, the fixture document only has one ISA, so searching for a second one is a valid query, but it doesn't exist.

>> parser.first.flatmap{|x| x.find(:ISA) }
=> Either.failure("ISA() segment does not occur")

When I pretty-printed the syntax tree of this particular file, it indicated a problem:

$ ./bin/edi-pp spec/fixtures/X279-HB271/1-good.txt
TransmissionVal(
  InterchangeVal[00501](
    SegmentVal[ISA: Interchange Control Header](
      ID.value[  I01: Authorization Information Qualifier](00: No Authorization Information Present (No Meaningful Information in I02)),
      ...
      ID.value[  I14: Interchange Usage Indicator](T: Test Data),
      SeparatorElementVal.value[I15](:)),
    FunctionalGroupVal[005010](
      SegmentVal[GS: Functional Group Header](
        ID.value[ E479: Functional Identifier Code](HB),
        ...
      InvalidEnvelopeVal(
        unknown transaction set "HB" "271" "005010X279",

With the HB element in the GS segment colored red. This is probably because the default parser configuration doesn't map those identifiers to the HB-271 grammar. I didn't see anything for 271 when I looked in lib/stupidedi/guides/005010/, so it's just not been implemented.

You might check the eligibility branch, which I think does have a grammar. It's not been merged, but should be safe to do so... it's just behind. If that seems worth pursuing, you should work with @irobayna to have it reviewed and merged.

[kputnam]

One other thing: I think you're right that we could use better examples of traversing a document. Most of the documentation and example code is generic and not for a specific grammar, so it can be difficult to understand "what code do I need to write to make this work?"

It's hard to pick one grammar that most users will directly relate to, because some users are doing health care, others are doing shipping, purchase orders, etc. But having an example that used a simple grammar and test file would demonstrate the general ideas.

Regrettably I won't be able to find time to do this myself. However, if you are able to contribute, please do, it will be welcomed! I'll be happy to review or offer guidance if you'd like.

[ghost]

Well, I appreciate your quick response. Can you guide me on how do I add new grammar to existing code and all the config changes that I need to make to accommodate that grammar. Also what is parameter that pretty_print method takes? I was not able to figure out as I couldn't find any documentation relating to that

[irobayna]

@rajeshyogeshwar have you tried using edi-pp to parse your file with?

This gem will install both binaries edi-pp and edi-ed

[ghost]

No, I haven't. Can you just guide me as in where do I start from. I have a valid HB271 document with me, I tried following the steps mentioned in readme.md file in 'reading section'. In case of using edi-ed or edi-pp, how do I use it? All I want is to parse the doument, and store the parsed information in key-value pairs.

[ghost]

I just tried and it seems to be working for X222-HC837, but when I tried with HB271 doc. It gave me following error

/var/lib/gems/1.9.1/gems/stupidedi-1.2.2/lib/stupidedi/config.rb:111:in `block (3 levels) in hipaa': uninitialized constant Stupidedi::Guides::FiftyTen::X279 (NameError)

Although I have added guides for X279/X279A1 HS270 HB271 and related config changes.

[ghost]

There is nothing in contrib folder relating to 00501 so do I need to add anything in there?
@irobayna I have used guides written in eligibility branch. Are those guides perfectly valid?

[kputnam]

I can't reproduce the problem, but here's what I tried (using ruby 2.1.0)

$ git clone https://github.com/kputnam/stupidedi/
$ cd stupidedi
$ git checkout -b eligibility remotes/origin/eligibility
$ bundle install
$ ./bin/edi-pp spec/fixtures/X279-HB271/1-good.txt
$ ./bin/edi-pp spec/fixtures/X279-HS270/1-good.txt

Both fixtures were parsed without error.

[ghost]

@kputnam i tried the steps you mentioned and voila it worked. May be I had messed up some configuration or missed out something. Thanks a lot for this short and perfect guidance. I am just concerned with HB271 and HS270. Is eligibility branch perfectly fine to use in production environment?

[kputnam]

I believe the grammars are correct, but the branch is a bit stale -- I think there have been bug fixes and other changes in master that haven't been merged into eligibility. Conversely, there are a few bug fixes in the eligibility branch that haven't been merged into master, but I think those bugs only applied to 270 & 271 parse trees (something to do with repeating elements).

My suggestion is to work with @irobayna to merge these branches (GitHub says there are conflicts), and as usual, make sure you have representative sample files from your trading partner for testing. The library is quite stable but the risk is always with trading partners that send or require non-standard data.