Export Empty File Question

Question

AETLE v6.3.12.13 x64

Hi,

I was just wondering in the Export Data Package Action does "Do Not Create Empty files" mean that the header (if there is one) is also included? Meaning that if "Create Header" is CHECKED and the resulting export file has no detail rows, and the only output row is the header - does this constitute an "Empty File"?

AND

If this checkbox is enabled and an "Empty file" is generated - will the this raise an error, we can then redirect in the flow?

For our use case we need to trap that there were no detail rows generated - but there may still be a header. We would still call this an "empty file" and wish to abort the rest of the package. 

Perhaps either way, it would be good for the documentation to stipulate what would happen in this situation.

 

Thanks in advance.

Hi Bruce.

I had a look at the source.

"Create header" has no effect on "Do not create empty files" checkbox
EG when the source has zero records the file is not created.

In your particular case, the best approach would be to add the "Abort on empty file" checkbox

I think at some stage we would need to review how we work with parameters variables ETC.
Having too many parameters is confusing for the users.

I have another question for you.
Have you ever worked with semistructured Excel files?
For example with multiple tables per sheet.
If so what was your approach?
 

Perhaps we should call it: 

"Abort when no data was found"

I think it more clear

Thanks Peter. That was how I thought it would work. That is, if there is nothing to output from the input then don't create the export file at all and abort. That way the next step in the workflow and take appropriate action.

Agree. (for me at least it would make it a lot clearer)

Hi Peter. Can't say I have.

But if a human can touch the file (or an automation script. eg. Python with appropriate libraries) then I would set up separate named ranges for each area with a separate reader for each. If I had to go that far and build an external script to do that step, then I would possibly split the sheet into separate workbooks (.xlsx) files at the same time and read them as a batch with a different transformer per each file.

Reading an excel workbook with parsing etc is very straight forward with the right libraries in something like Python - without that many lines of code. I would also possibly break the whole workflow up into separate packages. The first to receipt the initial file and split or put the names ranges in and then drop the revised file(s) off into a monitored folder and let another package process from there. That way, I have focused elements doing specific tasks that I can plug and play of I needed to.

It would all depend on how automated I needed to make it and what the downstream processing needed to be. But I am not averse to have small purpose-built scripts to massage the inbound file into more easily consumable things that then makes it clearer in AETL.

Does that help?
cheers