none
Correlation with 837P RRS feed

  • Question

  • For those of you that do a lot of work with the 837 P or I... I'm working on an aggregator pattern application. I need to set up my correlation based on information in the ISA. How can I do this since the ISA is stripped from each message?

    Thanks.

    G

    Monday, August 5, 2013 7:13 PM

Answers

  • Yep, been down this road.  This makes it much easier for you.

    What you need to do is:

    1. Debatch and process the 837 as normal.
    2. Copy to EDI.ISA06 and EDI.ISA08 to EDIOverride.ISA06 and EDIOverride.ISA08.
    3. Set EDIOverride.OverrideEDIHeader to True.
    4. Configure and otherwise appropriate Party/Agreement for the backend system.  The Identifiers configured there won't matter so much as they will be overwritten.  Add the Send Port to the Party.
    5. Route the clean 837's to that port with the EDI Assembler.

    You can do the context work in an Orchestration, via the referenced method, or in a Pipeline Component.

    • Marked as answer by gcooper Friday, August 9, 2013 5:48 PM
    Wednesday, August 7, 2013 9:33 PM

All replies

  • I think you will end up modifying schemas and maps.


    If this answers your question please mark it accordingly. If this post is helpful, please vote as helpful.

    Monday, August 5, 2013 7:53 PM
  • It depends on exactly how you need to aggregate the 837's.  If this is related to the previous post, did you confirm the requirement to re-batch at the Interchange level?  As opposed to the FG or ST.

    So, if you really do need to rebatch the Interchange, you have several options.  Here's one:

    1. Manually Promote ISA06, ISA08 and ISA13 (You will have do define you own ISA13 Context Property).
    2. Create a Sequential Convoy correlating on those properties.

    How to Promote ISA06, ISA08 and ISA13:

    Parse ISA13 from the ISASegment property.  ISA06 and ISA08 are already on the Context.

    In a custom Pipeline Component, Promote each on the messages Context.  In an Orchestration, force promotion by Initializing a Correlation Set on the Send Port.

    Monday, August 5, 2013 8:25 PM
  • Yes, I do indeed need to re-batch the interchange. The outgoing file needs to look just like the incoming file, other than a few fields within each claim that we enhance. I really didn't think it would be that difficult, but I haven't dealt with this requirement before. I'm wondering if the aggregator pattern is still the best to use. What do you think?

    Thanks.

    G

    Monday, August 5, 2013 8:59 PM
  • What I've decided to do is promote the filename in a custom pipeline so I can just correlate on that. One thing I've never done is correlate on a property that I've promoted through a pipeline. How do I set this up? Also, I'll need to set a batch release condition so that the application will no that once the last record is finished from that file it can release that batch. Also, something I've never done. 

    Boatseller, you mentioned that I should force correlation from my promoted property on the send port, but I'm not quite sure what you mean.

    Thanks.

    G

    Tuesday, August 6, 2013 2:51 PM
  • Correlating on file name may work depending on the Trading Partner.  That is because multiple ISA's may come in the same file.  There's no x12 rule that prevents that.

    Here's a blog explaining how to Promote Context Properties in an Orchestration by initializing a Correlation Set.

    http://blogs.biztalk360.com/property-promotion-inside-orchestration/

    Tuesday, August 6, 2013 3:46 PM
  • For what we do, our files come directly from trading partners with only one ISA/GS. So it should be a bit easier. thanks for the link. I'll check it out.

    G

    Tuesday, August 6, 2013 6:16 PM
  • Well....as luck would have it my requirements have changed. I no longer have to re-batch outgoing claims. All I need to do is make sure the ISA06 and ISA08 in each outgoing claim reflects what was in the ISA for the incoming file. Previously, we could just send the claims out with generic values as our target system didn't need that info because our incoming system was recording it. Our compromise is that as long as each outgoing claim retains this info I won't have to re-batch. I'm guessing I'll need to write these values in an outgoing pipeline component for them to appear in the ISA of the outgoing file. Is that correct, or is there a way to do it without having to do it in the pipeline?

    Thanks

    G

    Wednesday, August 7, 2013 7:51 PM
  • Yep, been down this road.  This makes it much easier for you.

    What you need to do is:

    1. Debatch and process the 837 as normal.
    2. Copy to EDI.ISA06 and EDI.ISA08 to EDIOverride.ISA06 and EDIOverride.ISA08.
    3. Set EDIOverride.OverrideEDIHeader to True.
    4. Configure and otherwise appropriate Party/Agreement for the backend system.  The Identifiers configured there won't matter so much as they will be overwritten.  Add the Send Port to the Party.
    5. Route the clean 837's to that port with the EDI Assembler.

    You can do the context work in an Orchestration, via the referenced method, or in a Pipeline Component.

    • Marked as answer by gcooper Friday, August 9, 2013 5:48 PM
    Wednesday, August 7, 2013 9:33 PM
  • Boatseller,

    Thanks for all of the input. I'm guessing I still need to use part of the aggregator pattern so I can just record the ISA information once and then loop through all of the claims in order to gather claim level info. There may be an easier way to just accomplish that simple task, though.

    G

    Friday, August 9, 2013 2:37 PM
  • Actually, no.  You can process each transaction individually. 

    The EDI.ISASegment property will be written to each debatched message.

    Friday, August 9, 2013 5:08 PM
  • Oh, yes, I realize that, but I have a header table that I am keeping the ISA info in. So I only need to collect the ISA information one time.
    Friday, August 9, 2013 5:48 PM