Skip to content
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

Missing UNZ segment terminator #142

Closed
GVG opened this issue Dec 2, 2019 · 8 comments
Closed

Missing UNZ segment terminator #142

GVG opened this issue Dec 2, 2019 · 8 comments
Labels

Comments

@GVG
Copy link
Contributor

GVG commented Dec 2, 2019

Hi! I'm serializing EDIFACT document and having issue with missing segment terminator of last (UNZ) segment. This is what I get:

......
......
UNT+000006+IJKL'
UNE+000001+EFGH'
UNZ+000001+ABCD

There is no ' terminator in the end of the document.
Is this correct behavior?

Code:

    public static byte[] Build()
    {
        using (var ms = new MemoryStream())
        using (var sw = new StreamWriter(ms))
        using (var ediWriter = new EdiTextWriter(sw, EdiGrammar.NewEdiFact()))
        {
            new EdiSerializer().Serialize(ediWriter, GetInterchangeModel());

            sw.Flush();
            ediWriter.Flush();

            return ms.ToArray();
        }
    }

    public class Interchange
    {
        public InterchangeHeader Header { get; set; }

        public Group Group { get; set; }

        public InterchangeTrailer Trailer { get; set; }
    }

    [EdiSegment, EdiPath("UNZ")]
    public class InterchangeTrailer
    {
        [EdiValue("9(6)", Path = "UNZ/0", Mandatory = true)]
        public int ControlCount { get; set; }

        [EdiValue("X(4)", Path = "UNZ/1", Mandatory = true)]
        public string ControlReference { get; set; }
    }
@cleftheris
Copy link
Contributor

Hi @GVG and thanks for your interest in the library.

This definitely should not be happening. So it is a potential bug in the serializer.

@GVG
Copy link
Contributor Author

GVG commented Dec 3, 2019

I've taken a look at the code and as far as I understand EdiWriter writes segment terminator when it begins serialization of next EDI segment. The problem is that UNZ is last segment and there are no subsequent segments to write last segment terminator.

I've also tried following variations of Interchange and none of them had that last terminator.

public class Interchange
{
    public InterchangeHeader Header { get; set; }
}

public class Interchange
{
    public InterchangeTrailer Trailer { get; set; }
}

public class Interchange
{
    [EdiValue("9(6)", Path = "UNZ/0", Mandatory = true)]
    public int ControlCount { get; set; }

    [EdiValue("X(4)", Path = "UNZ/1", Mandatory = true)]
    public string ControlReference { get; set; }
}

PS version is 1.9.5 from NuGet

@cleftheris
Copy link
Contributor

Hi @GVG ,

I finally figured it out. There was a bug with the EdiSerializer class when using Serialize overload that passes a plain TextWriter the internal EdiTextWriter was never closed thus not autocompleteing/terminating the current active structure.

Expect a v1.9.6 to land on nuget withing the day

@GVG
Copy link
Contributor Author

GVG commented Dec 5, 2019

Thank you very much!

@GVG
Copy link
Contributor Author

GVG commented Dec 10, 2019

Hi @cleftheris
I've tested 1.9.6 and it's only partially fixed. void Serialize(EdiWriter ediWriter, object value) behaves same way as before and I think void Serialize(EdiWriter ediWriter, object value, Type objectType) should too. But following code works fine now:

using (var ms = new MemoryStream())
using (var tw = new StreamWriter(ms))
{
  new EdiSerializer().Serialize(tw, EdiGrammar.NewEdiFact(), GetInterchange());
  var d = ms.ToArray();
}

Also I was told that last segment terminator must be followed by CRLF otherwise it's not a valid document. Do you know anything about this?

@cleftheris cleftheris reopened this Dec 11, 2019
@cleftheris
Copy link
Contributor

Hi,

Also I was told that last segment terminator must be followed by CRLF otherwise it's not a valid document. Do you know anything about this?

regarding the last CRLF it seems I have made a regression bug with the last change I made. I did this on purpose because I have not found any documentation stating that it is required when ending the document (especially if \r and \n are not included as special characters in the transmission grammar). I will make a new release to fix this for you.

I've tested 1.9.6 and it's only partially fixed. void Serialize(EdiWriter ediWriter, object value) behaves same way as before and I think void Serialize(EdiWriter ediWriter, object value, Type objectType) should too

I will give this another look.

cleftheris added a commit that referenced this issue Dec 11, 2019
@cleftheris
Copy link
Contributor

One more question: Before you changed to the overloads not requiring a EdiWriter where you disposing of the EdiWriter you where passing in the serialize method?

It is by design that these overloads of Serialize do not call Close() explicitly on the EdiWriter.
This allows the developer to potentially continue to write stuff with the same writer you created and dispose (implicit close) it or call close (explicit close).

I am thinking of running close on every serialize call just to be sure the developer does the right thing and I will see how it goes.

@GVG
Copy link
Contributor Author

GVG commented Dec 11, 2019

Thank you. EdiTextWriter was disposed by using block in initial variant, but this happens after I read and return the document. Current variant is fine for me.

Regarding CRLF I couldn't find any reliable or official sources, but my partner and some docs state that segment terminator symbol followed by CRLF in UNA is treated as whole segment terminator. Thus multi-line document must end with '\r\n otherwise parser counts it as invalid. Probably human-readable multi-line EDIFACT documents are not the best format to communicate between programs at all. https://docs.microsoft.com/en-us/biztalk/core/configuring-charset-and-separators-edifact

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants