This site uses different types of cookies, including analytics and functional cookies (its own and from other sites). To change your cookie settings or find out more, click here. If you continue browsing our website, you accept these cookies.
Recently we had a situation where installing the data packages was expected to take over 20 hours! We do not have the ability to run a machine undisturbed for this length of time at the office, and VPN automatically times out after 12 hours. Okay, so these items are company-specific, but how nice would it be to be able to download/install the data in smaller portions so you don't have to worry about setting up shop for 8-10 hours?!
I was able to copy the DataInstall.ini and name only the portions of the data I wanted to install in each session. But then I had to separate the installs into different network folders otherwise you end up overwriting the DataInstall.exe file, which users need for each install in order to register from a network location (for each install).
Needless to say, it took SEVERAL weekends and quite a few mistakes before I was able to do it this way successfully!
Please vote for data installs in smaller portions!
In order to perform audit-trail logging - it would be valuable to have 2 new capabilities
a) environment variables which show the workflow name; filepath; version; run start date and time; etc. For any worklows we build, we need to have a solid audit trail to be SOX compliant, so having this detail available as a data field to write and manipulate is essential
b) A logging component. What would be great is a component that you can drop on a workflow, not connected to anything, which is able to trap the start; end; runtime; version; etc of a workflow; and commit this to any output data format (CSV or ODBC etc). This logging tool would need to be able to capture the full runtime, so it would need to be the last thing that runs (which means it may need to exist in parallel to the main workflow in some way). This is not currently possible with a complex workflow with outputs, because it's not possible to identify when the entire workflow ended; or the runtime (since output tools don't have an onward connector to pass flow-of-control to catch the final end-time)
Again, both of these are necessary to meet audit requirements for workflows and prodcution-quality ETLs for BI data warehouses.