Introducing a new Script object and Script Editor and more!

[Michael_Tarallo]

What if you could prepare data (join, transform, STORE, etc.) using Qlik script - WITHOUT creating a standalone app - without sheets? Would you like that? Well, would you? Well now you can - introducing our new script object and script editor - with data preview and more! Watch this #qlik #SaaSin60 to learn more!

We have now added the ability to create Qlik scripts directly from the hub, ana managed in the catalog -  using a new and improved script editor.  Users can now build and deploy Qlik scripts upstream of analytics apps, which can be executed and result in output files in formats such as QVD and PARQUET that can be stored in the hub and used for analytics and AutoML applications.  The script editor also now includes a data preview feature, allowing users to get better insight when developing scripts.  This provides our customers with an improved workflow for preparing data, while setting the stage for future enhancements to analytics data prep capabilities.

• Watch More in 60: 
• Can't see the video? YouTube blocked by your region or organization?  Watch it here

[KHSDM]

Is this coming to on-prem?

[StefanBackstrand]

@Kunal12164 If you want to automate that process (not sure why though), you should look into AWS S3 instead, where you can write back files, iirc.

[StefanBackstrand]

@Michael_Tarallo I've been playing around with this a bit - do you know of any plans of showing the current data model in a script  (since it does not have an app - and hence no data model viewer of its own)? It's sometimes hard to visualize the result of iterative and exploratory script work against new and unknown sources - especially without a data model viewer near at hands.

Is there a way to provide input to this feature?

[Or]

@Michael_Tarallo Thanks for the clarification - if I understand it correctly, this is the first step towards being able to refer to scripts directly from other apps/scripts, which would indeed be quite helpful once available, but not something that's significantly different from just using an app as things currently stand.

[Michael_Tarallo]

Hi Guys - thank you all for you comments and additional questions - I wish I could reply to each comment / question individually  -  but it seems I cant in this platform and need to consolidate the replies here:

@StefanBackstrand  - thank you for your comment - hope you've been well , and good to hear from you 🙂

@barnabyd  - thanks for your comment - agree - and I wish I could tell you how features get priority, that remains a mystery to me, and I'm sorry I can't be more clear on that topic.

@paulcalvet - there will be a new block in app automation to include these scripts released soon.  In regards to consumption - please see this video https://youtu.be/bXW-iHMrNjI and this blog https://community.qlik.com/t5/Official-Support-Articles/Qlik-Cloud-Monitoring-Apps-Workflow-Guide/ta... - regarding the cloud monitoring apps - they might fill that need. re: 5GB - you can submit an idea here:  https://community.qlik.com/t5/Ideation/ct-p/qlik-product-insight 

@Kunal12164  - I have opened an improvement on this which is actually In devleopment: https://ideation.qlik.com/app/#/case/281144?currentProductId=9da99bc1-0dfb-4471-8e12-d23685578c43&se... - the work-around is to STORE to supported cloud file storage like Dropbox etc.

Stay well everyone!

Regards,
Mike T

[it2b]

I like this feature and principle. Optional store is nice. Often we drop the table after store in this type of script (certainly with huge tables or undesired linking at this stage). Unfortunately we lose the output information in that case (unless we manually tune the script). 

[CreoLabs]

Nice direction 🙂 Will be very useful in the future for scripts reuse between applications.
Still, guys... the basics... Script object shouldn't create the data model. It should only produce the final tables.
currently, after the script finishes to run, it makes all synthetic keys... what for?
Please remove this part ASAP because it totally ruins the functionality of the Script vs App...
@StefanBackstrand you don't need the data model - the intent of the Scripts should be a proper ETL process for creation of all needed entities (extracts, transformations and final Dims and Facts)... then you just run it and enjoy the flow without modeling because the modeling itself should be prepared in separate app (or the final analytical one)

[paulcalvet]

      @it2b  I drop the table and I have the output

[it2b]

@paulcalvet Thanks, yes the output is there, I mean to have the output preview of the table. That is gone after the drop which I guess makes sense. 

[StefanBackstrand]

@CreoLabs I agree with the sentiment, but creating tables in an exploratory phase also requires to check if data matches up. I would very much like to see what the model looks like for several assets before dumping them to disk. Context for stored assets are equally as important.

Also, when working iterative with multiple temporary tables, resident loads and joins towards a complete picture, sanity checks are required.