On one of our current projects after completing initial development we got to a point where we needed to test our Boomi application to see how it could handle very large EDI files. For our first test we tested an 834 EDI test file with many enrollments and while doing this testing we got unexpected outputs from our maps that we had not previously seen. It was tough to really gauge in our application to see what exactly was going on in the mapping but the fact that at one point it was working with smaller files led us to assume that this was an error in our profiles that was getting exposed.
So in order to debug this solution we created simplified process that only contained a simple map in which our EDI profile mapped to itself and output the results to a file. This in theory should output a file almost identical to that of the input file. You can see this test process and the test file used below:
The sample file above has highlighted the two enrollments in the sample file. When we ran that test file through the sample process the screenshot below is the newly generated output:
You can see here that now instead of having two enrollments we now only had one enrollment in the output EDI file. Also upon closer inspection we can see that all the unique segments that existed between the two enrollments all moved under the first enrollment. Based on the output document we could clearly see that any segment (or segment within a loop) that was duplicated had one of the duplicates removed from the document. So in the output document it looks like there is only one enrollment but the only reason it looks like that is because the INS segment for the second enrollment had been stripped out from the output document because the segment for the second enrollment was exactly the same as the first.
Based on our analysis of the output EDI file we took a look at our EDI profile and noticed that the 2300 loop for the 834 EDI profile had a looping option set to Unique as seen below.
The Boomi documentation perfectly explains the issue we were having: “Unique means only unique instances of a loop or segment will be written. If two (or more) loops or segments are identical, then only the first instance will be written.”
In this case what we wanted was to set the looping option to Occurrence. This makes sense for what we were trying to do because if you remember this whole issue started because we were trying to do some performance testing on large files. When generating our test files we copied and pasted many enrollments just to get the file large enough to test the actual performance. So by changing it to Occurrence we prevent Boomi from stripping out any duplicate segments or loops and thereby end up getting our expected result.
Dell Boomi AtomSphere
The Dell Boomi AtomSphere integration platform is a shared-everything, multi-tenant platform that supports cloud-to-cloud, SaaS-to-SaaS, cloud-to-on-premises, on-premises-to-on-premises and B2B integration. Boomi AtomSphere supports real-time integration and elastically scales to meet high-volume needs in mobile, batch (ETL) and EDI environments. Easily accessed via a browser, it delivers an impressive range of integration, master data management (MDM) and platform extension capabilities.
Tallan Integration Solutions for Dell Boomi
Tallan is a certified Dell Boomi Partner specializing in iPaaS platform integrations. Leverage Tallan’s vast integration experience for your AtomSphere platform needs. Our certified architects and developers provide the expertise, best practices, and guidance to deliver a successful integration solution.