UNH and UNZ segments in separate classes about edi.net HOT 15 CLOSED

I have already implemented it in the past weekend: see pull request #46

It was the flow in serializer that bypassed the creation of segments (TryCreateContainer method) on when handling the start of the message (UNH) or the end of the transmission (UNZ). I changed this flow so it also tries to create a segment container in the run of the loop where the UNH and UNZ are handled.

from edi.net.

@bugproof

An EDISegment can represent any given tag. EDIMessage can only mean the well known structure defined by two tags the message header & trailer.

• UNH & UNT in EdiFact
• ST & SE in X12
• MHD & MTR in Tradacoms

Edi Segment is general purpose and can work with message tags too but consider using for message structures the more specific EdiMessageAttribute

from edi.net.

Structures are always defined by classes. It is up to the developer decide where to put the annotation. Since a class representing a message can rarely be used for anything else it is true that the annotation is more appropriate to be placed on the class definition itself.

from edi.net.

Hi there, I had this problem too, I solved it marking the UNH as EdiElement instead EdiSegment and adding the MessageRef inside the [EdiMessage] Class, for the UNZ I simply do not make a EdiSegment for it and put both fields in the Dokument class, this would give you something like the following (ORDRSP). Reason is here

public class ORDRSP
{
    public Dokument_Kopfsegment Dokument_Kopfsegment { get; set; }

    public List<Nachricht> ListNachricht {
        get; set;
    }

    [EdiValue("9(6)", Path = "UNZ/0/0")]
    public int Anzahl_der_Segmente {
        get; set;
    }

    [EdiValue("X(14)", Path = "UNZ/1/0")]
    public string Referenznummer {
        get; set;
    }
}

[EdiPath("UNB")]
[EdiSegment]
public class Dokument_Kopfsegment
{
    #region Properties

    public Absender Absender { get; set; }

    [EdiValue("X(14)", Path = "UNB/5")]
    public string Anwendungsreferenz { get; set; }

    [EdiValue("X(14)", Path = "UNB/4")]
    public string Datenaustauschreferenz { get; set; }

    public Empfaenger Empfaenger { get; set; }

    public Erstellungsdatum Erstellungsdatum { get; set; }

    public Syntax_Bezeichner SyntaxBezeichner { get; set; }

    #endregion Properties
}

[EdiElement]
[EdiPath("UNB/1")]
public class Absender
{
    #region Properties

    [EdiValue("X(35)", Path = "UNB/1/0")]
    public string ID { get; set; }

    [EdiValue("X(4)", Path = "UNB/1/1")]
    public string Qualifier { get; set; }

    #endregion Properties
}

[EdiElement]
[EdiPath("UNB/2")]
public class Empfaenger
{
    #region Properties

    [EdiValue("X(35)", Path = "UNB/2/0")]
    public string ID { get; set; }

    [EdiValue("X(4)", Path = "UNB/2/1")]
    public string Qualifier { get; set; }

    #endregion Properties
}

[EdiElement]
[EdiPath("UNB/3")]
public class Erstellungsdatum
{
    #region Properties

    [EdiValue("X(6)", Path = "UNB/3/0")]
    public string Datum { get; set; }

    [EdiValue("X(4)", Path = "UNB/3/1")]
    public string Zeit { get; set; }

    #endregion Properties
}

[EdiElement]
[EdiPath("UNB/0")]
public class Syntax_Bezeichner
{
    #region Properties

    [EdiValue("X(4)", Path = "UNB/0/0")]
    public string Syntax_Kennung { get; set; }

    [EdiValue("9(1)", Path = "UNB/0/1")]
    public int Syntax_Versionnr { get; set; }

    #endregion Properties
}

[EdiMessage]
public class Nachricht
{
    [EdiValue("X(70)", Path = "UNH/0/0")]
    public string Nachrichtenreferenznr {
        get; set;
    }

    public Nachrichten_Kopfsegment Nachrichten_Kopfsegment {
        get; set;
    }
}

I hope this can help you a little bit.

from edi.net.

Thanks for your help, I could restructure my messages to be close to your example, however I would expect that all logical elements (UNB, UNH, UNT and UNZ in my case, following the diagram of #14 ) would be null if the serializer was designed to not serialize these elements to EdiSegments.

Maybe it would be good that either these elements are all serialized to EdiSegments or none of the elements would serialize to EdiSegments. My personal preference would still be to support to serialization to EdiSegments because I could create a namespace where I would implement all segments (including structural segments) and then compose messages from this collection of segments.

from edi.net.

I understand you as I had the same thoughts when I first started designing the POCO classes but like @cleftheris said, it is not possible in the current implementation, I guess we will have to implement it or wait for him to implement it as enhancement.

from edi.net.

Nice! Then I guess we will have to wait for him to merge it =D But nice to know, I will prepare the POCO classes I already have in that way. Thanks!

from edi.net.

Hi all great discussion by the way. Sorry it took me a long time to answer, I had the flu.

@KoosBusters the PR looks good. I will try it and publish a new version v1.2.2 asap

Just for the sake of clarity: there is no good reason why this was not supported from the beginning other than that it was not considered by the author (me) important at the time. Since all projects come out of necessity Edi.Net came out of a large project for a client I was working for in 2015. The only reason I did not support this earlier? I did not realize it would be so simple 👍

Thanks guys

from edi.net.

@KoosBusters I am looking at your sample and I am not sure why you would merge the interchange structure with the message itself.

The library has a way to skip the interchange information if all you need is the content of the message. In your test you neither skipped nor included the interchange section. You have merged the 2 into one by sub-classing. Although this seems to work in the scenario where there is only one message (quote) inside the transmission and only one group; what would happen if there where more.

Anyway if I split the interchange and the message into separate classes the Message header will not bind. I will commit the failing test and try to fix it.

from edi.net.

@cleftheris I have a situation where the implementation guide specifies that only 1 message can be included in 1 interchange, that is the reason why I landed at this funky test. I will take a look at your test as well, I would like to see why it fails in that case.

from edi.net.

@cleftheris just handling the start message separately fixed the unit test for me: KoosBusters@f3f39de

I also tested this fix succesfully with a list of EdiMessages: I duplicated the message content inside the interchange and created an variant of the current Interchange that expects a list of Quote2 objects: KoosBusters@7114384

from edi.net.

@KoosBusters great! please make a new pull request with your changes? And I will complete the release. Thanks again for all the help.

from edi.net.

@cleftheris sure! Just created PR: #47

from edi.net.

What's the difference between [EdiMessage] and [EdiSegment] any way? Sorry, I'm new to EDI. I see it's used interchangeably. When should we use one over another? I'm currently working at IFTMIN message models.

from edi.net.

so [EdiMessage] should be treated more as an aggregate of segments - the final model with headers, messages and trailers that is going to be serialized/deserialized. Does it ever make sense to use this attribute for properties as well?

from edi.net.