xlate / staedi

StAEDI - Streaming API for EDI: Java library featuring a reader/parser, writer/generator, and validation
Apache License 2.0
123 stars 35 forks source link

Edi 835 Never Emitting a START_TRANSACTION #462

Closed FloodCreux closed 3 months ago

FloodCreux commented 3 months ago

Describe the bug When attempting to read an 835 message in scala, the reader never emits a START_TRANSACTION event.

To Reproduce I have attached the test file I am using as well as the schema files used to parse.

Run below code in a test, transaction count results in 0 with a breakpoint on START_TRANSACTION never being hit:

def getTransactions(content: Array[Byte]): Int = {
    Using.Manager { use =>
      val stream = use(new ByteArrayInputStream(content))
      val schema = SchemaFactory.newFactory().createSchema(/** PATH TO SCHEMA **/)
      val reader = use(EDIInputFactory.newFactory().createEDIStreamReader(stream, schema))

      @tailrec
      def getTransactions(result: Int): Int = {
        if (reader.hasNext) {
          val event = reader.next
          event match {
            case START_TRANSACTION =>
              getTransactions(result + 1)
            case _ => getTransactions(result)
          }
        } else {
          result
        }
      }
      getTransactions(0)
    }.get
  }

Expected behavior Total transaction count should be 3

Additional context 835 Schema Definition:

default.txt transaction.txt types.txt

Test File: 835.txt

FloodCreux commented 3 months ago

I believe I may have discovered my issue and that I was opening too many readers to do things that I could have done with a single reader. For some reason, when I used multiple readers on the same underlying byte array of data the control schema was set to null. I can handle this in the START_INTERCHANGE event to confirm the control schema is set properly on a single reader and use that reader to parse the entire message.

MikeEdgar commented 3 months ago

That makes sense, I hadn't yet gotten your code to run (I'm a bit new with Scala), but I did notice what appears to be recursion and the opening of multiple readers.

FloodCreux commented 3 months ago

Yea, due to this I've actually pivoted my entire approach to use a single reader which I think is much cleaner so a win/win on my end