Hi Meike,

It is indeed currently not possibly to use the ADLS functionalities from the Developer environment. We suggest using the ADLS toolkit published on the cloud to create a SAS-token (with an appropriate lifetime) which you can then use locally. Is that a workable workaround for you?

Kind regards,

Roxanna

Hi @meikedewith 

The DEX library intentionally does not expose the access key of the ADLS account, as these provide the keys to the kingdom. Instead you can use the Datalake Tools AIMMS app, to create a SAS token that you can use to provide access to the ADLS account. 

I've just updated the datalake-tools repo for the Datalake Tools to become a little bit more intuitive in it's use. You can clone the repo, and publish the app in the cloud account for which you want to create SAS tokens to access its assoiciated ADLS account.

With the app you can create Account SAS tokens (giving you access to the account and any container in it), as well as Container SAS tokens (giving you more fine-grained access to just a single container), and it also lets you create or delete containers (i.e. file systems) within the ADLS account. 

My advise would be to create a new or select an existing container where you want to read/write, and create a long-lived SAS token that you can use for accessing the ADLS account from your desktop. How to set this up is described in https://documentation.aimms.com/dataexchange/dls.html#authorization.

Please make sure that you don't store the files in api-init to your git repo. 

Hi Marcel, Roxanna,

Thanks a lot for your response! Unfortunately, the SAS Token option (which I had indeed found as well) also does not seem to work for me.

I have an open ticket regarding this issue (#58151) so I’ve sent some more information and screenshots there (possibly confidential, which is why I’m not sharing it here, but of course I will share the eventual solution also here). Could you have a look and let me know if there’s anything I’ve set up incorrectly?

Thanks again!

Meike

Hi Meike,

The default timout for the generated SAS tokens in the previous version of the app was only 600 seconds, and not visible on the page to create a container SAS token, which may have led to SAS tokens that were expired before you actually got to use them. The latest version of the app also allows you to specify an expiry in terms of days which makes it much easier to create long-lived SAS tokens.

Besides that, container SAS tokens are very specific about the order in which the permissions are specified, which was wrong in the previous version of the app.

I've tested the SAS URL generated by the latest version with Azure Storage Explorer and i could connect and transfer data just fine with it.

So, my advise is to update the Datalake Tools app

Hi Marcel,

I’ve updated the DataLakeTools app and this indeed solved the problem. Thanks a lot!