Just curious what the plan is for Automise and any rough timeline etc…
TJ
We are still working on it. At the moment we’re working on high dpi support, which (amongst other things) involves recreating thousands of images from png to svg (for scaleability) - it’s a process that is taking far longer than I envisaged (it’s incredible how many images there are!). We’re chipping away at it as fast as we can.
As for features, some minor UI changes, real high dpi support (no more blurry fonts etc), reworking many of the actions (tidy up, improve ui, error reporting etc) - major focus on the file transfer actions (FTP/FTPS/SFTP) - changing client library to improve performance and compatibility. Ability for ATCMD to run in a docker container (yes people have asked for it, AT5 does not work in docker). We’re also taking a compiler upgrade and some core library upgrades which have improved general performance and startup times.
I had hoped for a 2020 release, but it’s looking more like Q1 next year now.
It’s not been a great year, with covid disruptions (closing the office, getting us setup to work from home etc) - we’re finally getting into the swing of working from home, zoom meetings etc.
Thanks for the update Vincent, these are indeed difficult times. Any hope of getting some more web service support (REST, SOAP complex data types etc.) in there as well? I don’t suppose compiling down to a stand alone EXE is possible with the new compiler, is it?
Thanks, TJ
Hi TJ
REST/GraphQL client - yes (+json support) - we’re still experimenting with how the json support would look, the initial plan is to do what we did for the xml actions, but we are looking into possibly (not making promises) introducing a json variable type.
SOAP - there are Web Service actions in AT5, not sure how up to date they are, I’ve not used soap in many years.
Compiling to exe, no. The product was never designed to do that, and there are a lot of complex technical challenges in doing that. We did some R&D on it a few years ago (not the first time) and concluded we would need to rewrite every action in a scripting language (some are native code, some .net and some javascript) to make it possible. That’s unlikely to happen due to the libraries needed for some complex actions (like S/FTP/S, SSH etc).
Thanks for the update. I was never able to use the SOAP web service actions because the ones I was interacting with returned “complex” objects and AT just couldn’t deal with it… Good news on the REST front though!
Thanks, TJ
Do you know of any public services we could hit to test this? I’d certainly like to see what we can do with this.
I had a quick look at the web service actions over my coffee this morning and I can see why they don’t cope with complex objects… because AT doesn’t really have a complex object type to store the results in - that is part of the R&D we are doing for the json support - yet an other reason to put more time into this.
1 Like
Thanks for looking into it 
Bump. Any update on AT6?
Thanks, TJ
It’s still in progress. We hit some technical issues with the high dpi support (bugs in delphi) and ended up switching back from svg’s to png’s - and we are still working to resolve many other issues with high dpi - it’s looking likely that we will ship with high dpi support disabled due to some of these issues that we have so far been unable to resolve. It’s extremely frustrating considering how much effort we have put into this.
We’re still experiementing with json/graphql and various other ideas - all of which really need a dynamic object type which can be queried. We’re trying to fit this into our variables architecture and that is a lot of work - making sure we don’t introduce new bugs with it.
Progress is much slower than I would have hoped - we’re a small team with limited resources, so it’s very difficult to provide any ETA’s.
Just thought I’d check in again regarding AT6 progress… Thanks, TJ
Still being developed - things are taking much longer than hoped. The high dpi changes mean we need to do a lot of work on Action Studio, and we are still working our way through the thousands of images that need replacing (it’s a task I wish we had never started!). There are still niggling high dpi issues we are working to resolve.
We’re also still working on replacing the client libraries for FTPS/SFTP/SSH with a more reliable and compliant library, Image processing (the current library has dependencies that will not work under docker) and a few others. Evaluating candidate replacements is time consuming but we are slowly getting there.
I can tell you the AT6 IDE is much snappier, loads in half the time of AT5, loading large projects is 300% faster (rewrote the parser to avoid memory allocations) and the stepping engine is about 50% faster.
I’m hopeful we will get it released this year, that’s about all I can tell you right now.
Thanks for the update Vincent…
I’m feeling crazy, so I thought I’d check in and see what the current state of AT6 is… TJ
We’re still working on it - there’s also a lot of other work being done - such as the website, online documentation (moving away from confluence) - these impact on all of our products.
All I can tell you right now is that we plan to have major releases of all our products this year and we are working towards that as quickly as we can.
Taking another swing at it… Any update on AT6 and/or its future?
Yes, we’re way behind on getting the release done. We have very limited resources so they are streched pretty thinly as we work though a bunch of technical debt. At this stage I am considering cutting some planned features just so we can get a release out (we’ll work to add those in an update).
Automise (and FinalBuilder) are rather complex applications, native code that hosts the .net clr and multiple scripting engines - a bunch of the actions are written in c# and javascript. We have migrated most of the .net framework code to dotnet 8, but there are still a few parts that are proving next to impossible to get working, so we will have to rewrite those as native code (windows scheduler support is one of those).
The other area we were looking at to rework was scripting - it’s currently based on active scripting (javascript &vbscript) - which pretty much legacy engines with no future development. Sadly we have yet to find a workable solution to this - having gone down the rabbit hole with v8, spidermonkey, duktape and a bunch of other javascript engines - all of which had limitations that made it impossible to provide the level of integration that we have with active scripting - com support is still important with things like wmi, office etc.
Then there is high dpi - we have migrated the code and all our third party dependencies to Delphi 11.3, with a bunch of other versions in between, all of which have been dismal when it comes to high dpi. Most things are working well, but we still get burned with bugs in the delphi vcl occasionally - so high dpi support will be a “preview” while we try to resolve those last annoying issues.
So all up, AT6 won’t be some earth shattering release chock full of new features - more of an under the hood refresh. We have done a lot of work on the internals, to reduce memory usage and improve performance. We did also investigate migrating to 64bit - but that also brings up issues with integration with some third party products that we will need to solve.
Like previous releases, we will keep working and adding new features over time.
TLDR; AT6 is still in development, taking much longer than planned, but we will get it out in the coming months.
Thanks again for the update!
For all its flaws, VBScript still woks well for what it does, so hopefully if you do find a replacement, the old engine will still be an option either log term or while transitioning code…
Good luck, It sounds like it was/is quite the undertaking…
TJ
VBScript will still be available in AT6, however it will be marked as deprecated - with a view to removing it in the future - Micrsoft have already said that it will be removed from windows in the future.
If you are using VBScript at the moment, I would look at migrating those scripts to Powershell.