I've used this trick a few times so I thought I should share it on the blog before I get run over by a bus.
Often we (developers) are asked to produce or consume data files for integrations with 3rd party systems. Even with the emergence of web services there are still many many times where the preferred method of interchange is file based, typically these are bulk (high volume) transactional exchanges. Think payments between banks etc
For the systems I've worked on we have solved this with .csv delimited inbound and outbound files. We have also utilised fixed width files, the majority having old school multi-format layouts with a traditional header, detail and footer structure which has some advantages over .csv.
For now, I will also ignore that we could have also provided XML or JSON payloads as part of a real-time integration.
As you can see, there are numerous ways to skin this cat. However, this is a 2E and Plex blog so for today, let us concentrate on:-
- How you might build and consume files into a 2E based application.
- How can we create a multi-format flat file using purely Synon logic only?
Let's fire up a 5250 session and explore an unsung feature in 2E that helps remove the complexity of building these flat files.
What are we going to build?
An extract file with a header record, 10 detailed transactional records and a footer which denotes both EOF as well as have a total for basic validation. In the real-word this may include hash total etc
An example of what this file data might look like is below.
Back in 2E, first define a file with one Known By (Numeric 9.0) should be suffice for most integrations and a second field (Has relation) of 'Flatfile Data' - Type TXT and length of 500 (or whatever length works for your environment). RP4 has better field limits than RPG.
I've called my file FIXFILP.
Now we need to build the data record, usually you would start concatenating the data values together to meet the design specification of the receiving system and handle those pesky FILLER57 fields etc that always appear from somewhere.
This involves dozens (if not hundreds) of lines of code to concatenate the data. The resulting action diagram is often difficult to understand and cumbersome to maintain.
What if there was an easier way to build up the data with the ability to easily reorder the fields and cater for changing field lengths. Well there is, using a neat unsung feature of 2E arrays.
2E keeps track of the last record to be added, changed or read in an array, a sort of cursor I guess. This is available in action diagram logic hidden in the ELM context. (ELeMent).
The only 'built in' function that can use the ELM context is a *CVTVAR.
First create an array with the data fields you would like to appear in the dataset, this can be header, detail 1, detail 2, footer etc. It doesn't really matter for a flat file process. To keep it nice and simple I have made up some generic fields names with various data types.
I've keyed these arrays based on the Record type of HDR, DTL and FTR. You can do how best suits your use case. All the arrays are set with a 'Numer of Elements' of 1 record as I don't need to use the in the traditional sense. I just need a pointer to an ELM in memory.
But we are not done. I've ready other blogs that talk about ELM and they do a pretty good job of explaining the outbound example above. But not many people realise that depending on whether you are using the ELM context as Input or Output, is the equivalent of constructing or deconstructing the data. So yes, this method can be used to unpack flat files also. :-)
As long as in the receiving function you have created a shell array record. You can use ELM to move the data into the array and then standard RTVOBJ functionality to retrieve the record in its deconstructed form.
An example below of a couple of screens that I rushed together showing the data string and the subsequent fields.
Thanks for reading.
Lee.
