Thinkwise Platform release 2022.1

Last night I've run the upgrade to 2022.1 and although everything seems fine, the authorizations of my trainees that where in a separate tenant got stripped of their SF rights in the IAM and on the DB (no more End User rights). Anything incorrect in the upgrade script or did I do something wrong? 

Hi Freddy,

An update of the Software Factory application indeed re-provisions roles for the user group ‘sf_developers’ of the default tenant and does not leave any other role assignments to user groups intact, regardless of tenant.

I understand that this is very inconvenient for your scenario. Please submit a ticket and we’ll look into resolving this for future releases.

Note that re-assigning SF roles for the the trainees’ user groups will also automatically grant them End User rights for IAM.

I've got a question about the "Redesigned deployment processes”. I'm super exited about this because i see much value in this for the automation of the development process.

We have lifted all infrastructure for the Software Factory development to the Azure cloud. The database(s) and application servers (web apps) are running in the cloud.

I read that the application server writes the files to some location. How is this designed to work with application servers that are running in the (Azure) cloud?

At this moment we are running on SF 2021.2 and the Windows GUI is writing the files to the local c:\Temp folder.

I read that the application server writes the files to some location. How is this designed to work with application servers that are running in the (Azure) cloud?

@Anne Buit @efitskie Same question and challenge for AWS Cloud from our side. Would prefer to get a recommended solution from Thinkwise, instead of having to figure this out ourselves!

When you cannot directly perform product rollouts and/or synchronisations, the scripts must indeed be somehow accessible to use in conjunction with the deployer (or some other tool).

The Software Factory allows for writing these to disk, but this is not the only option. The deployment scripts and sync scripts can be pulled from the Software Factory via the API.

You can access the code files after the source code has been generated as following:

indicium/iam/sf/code_file?$filter=project_id eq 'TEST_AB' and project_vrs_id eq '1.40' and code_file_generated_code ne null&$select=code_file_id, code_file_generated_code

The same can be done for the synchronisation scripts. After the API add_job_to_generate_sync_script has been used and the job is done, the sync scripts can be accessed as following:

indicium/iam/sf/sync_script?$filter=project_id eq 'TEST_AB' and project_vrs_id eq '1.40'&$select=sync_object_id, sync_script

The sync scripts will be available in the response

I hope this helps in automating the deployment when direct access from the Software Factory environment to the rollout target environment is not possible and access to disk is not an option.

It is possible to mount Azure blob storage as a volume in Azure Web App for Containers and in AWS Elastic Beanstalk via Amazon EFS but this might be more trouble than using the API to access the scripts.

@Anne Buit Thanks, good to know we can access the files through API calls as well. Nevertheless, I'm struggling to understand how we could streamline our PROD deployments after upgrading to Release 2022.1.

Currently we simply run the ‘Create deployment package’ task, which writes the package to an agreed upon network folder, right from the SF. Then IT Operations simply runs the twdeployerGUI.exe in order to execute the PROD deployment.

I guess using the API's would mean we need to run the API calls using another tool from another location (with access to the target network folder) and then save the files there.

Alternatively, introducing Amazon EFS would be an additional File Storage location, while we already use S3 for our Custom Application.

Since the Write file process action now (sort of) supports writing files to S3 (and other file storage locations), wouldn't it be rather simple and more straightforward if Thinkwise would use the File Storage location functionality for writing these SF files too?

Yes, it would be required to have some kind of agent that has access to the (on-premises?) network folder to access the API’s and write the files. Storing the files in S3 would also require an agent with access to S3 to move the files to said network folder. There are various CI/CD tools that can help with these kinds of tasks.

The Create Deployment Package task is an orchestration of various jobs, all executed by Indicium, including several jobs that write files to disk. In earlier versions of the Software Factory, these actions were executed by the GUI, which often has access to local network locations but which also made it notoriously difficult to automate.

We can look into allowing the Software Factory to use other types of storage instead of disk storage in processes that write files. In all scenarios, a shared/mapped file storage or an agent that acts as a bridge between the stored files (API/S3/...) and the on-premises file systems will be required if the deployment is initiated on-premises and the script generation is done in the cloud.

Hi @Anne Buit , I have a follow up question about this:
Because we will be using the Thinkwise deployer for upgrading our projects we will be needing the manifest file which is normally provided with a deployment package. Is there a way to access the linked manifest the same way as above? 

Excellent question. There is a function that generates the manifest content on-demand for the current version control and subsequent current generated code files. But as far as I can see, this function cannot be accessed through the API.

I’ve taken the liberty to create ticket 2960S for this.

Note that this manifest will only be usable for new installations of the product and upgrades of the currently configured version control. It is possible to have a manifest contain multiple products and/or incremental upgrades, but this will require the manifest to be created manually (or at least, not with the Software Factory).

@g.c.d.vanderschoot a platform improvement has been released that allows the manifest to be accessed via the API.

Note that the manifest itself is json-formatted, so the OData API will return it as nested json. Any json-deserializing client will yield the proper json file.

It is possible to mount Azure blob storage as a volume in Azure Web App for Containers and in AWS Elastic Beanstalk via Amazon EFS but this might be more trouble than using the API to access the scripts.

@Anne Buit Amazon EFS is apparently not supported with Windows-based EC2 instances, as noted here.

The AWS alternative for Windows servers is Amazon FSx, but we can't find any confirmation that this service works with Elastic Beanstalk.

Has anyone at Thinkwise tried and tested a solution to successfully write files from Elastic Beanstalk? 

The same can be done for the synchronisation scripts. After the API add_job_to_generate_sync_script has been used and the job is done, the sync scripts can be accessed as following:

indicium/iam/sf/sync_script?$filter=project_id eq 'TEST_AB' and project_vrs_id eq '1.40'&$select=sync_object_id, sync_script

The sync scripts will be available in the response

I hope this helps in automating the deployment when direct access from the Software Factory environment to the rollout target environment is not possible and access to disk is not an option.

It is possible to mount Azure blob storage as a volume in Azure Web App for Containers and in AWS Elastic Beanstalk via Amazon EFS but this might be more trouble than using the API to access the scripts.

FYI: be aware that simply parsing the JSON from the sync_script API call will break your Sync to IAM! The sync_script response includes both the “sync_object_id”: “post_sync” (normally used as part of the ‘Synchronization to IAM’ process) and the “sync_object_id”: “post_deployment” (normally used as part of the ‘Deployment Package’).

If you don't do this the deployment will cause errors due to the duplicate declared values:

And one more thing about the “sync_object_id”: “post_deployment” : the sync_object_id's are returned in the API based on alphabetical order, so it is by default nót added at the end of the script when parsing, where it is supposed to be executed.

Hi all,

I just did an upgrade to 2022.1 on Azure DB for the IAM and the SF. For some reason the SF was pointing to a default develop_server as a DB server which does not exist. Due to this SF was not accessible to developers.

I managed to log into IAM and point the SF to the correct DB server and problem resolved.

Not sure if anyone else faced the same so just a heads up.