Deployment issue; creation from SF in Azure#1 to Azure#2

Hi Alex,

The Custom pool user credentials are only able to be configured by using the Universal GUI. That is done because the required Encrypting of the credentials can only be done by Indicium. Therefore the Windows GUI cannot safely deal with these credentials.

In the Release notes we dedicated a paragraph to it: https://docs.thinkwisesoftware.com/blog/2023_1#deployment---pool-user-credentials

Both the Software Factory* and Intelligent Application Manager are available to open with Universal GUI. IAM in its entirety, and the SF only the parts that may need custom pool user credentials.

It also requires the data protection to be configured, more on that here: https://docs.thinkwisesoftware.com/docs/deployment/indicium_encryption

Hope this helps!

That was quick! It helps, thanks very much, Mark! 😊

Since we need an app registration at the "other” Azure in order to create a key vault, we're waiting for a 3rd party to create this. In the meantime, we'd like to ask some questions regarding this process if you don't mind.

If we understand you correctly, we create a new application in the existing IAM, yes? When the configuration is complete, including encryption settings, we can create the application at the "other” Azure from the SF.

How would we link the new application in the “other” Azure environment to its own IAM on that Azure environment? Can this be done at all, or is the production application always linked to the IAM that configures the development-  and test environment as well?

Hi Alex,

Once the pool credentials are set up correctly, you should be able to perform the Creation steps on the Production environment from your Development environment Software Factory; Although we do recommend Deployment packages more as this can be both used for rolling out a new application and upgrade an existing application in the correct order.

Synchronization to IAM from the Development environment can be done by setting up an IAM configuration in the Software Factory via menu: Maintenance > IAM configurations. Here you can also set custom pool user credentials. Note that this requires Universal GUI to set up successfully.

Once you have successfully synced the model and branch to the production IAM, an Application record has to be created. You can do that manually in the Production IAM, but you can also let that happen automatically by utilizing Post-synchronization code. In this code you could create a record in table gui_appl with all the necessary configuration. And lastly set it Active, to allow users to log onto the application.

I hope this is sufficient 😄

Thanks Mark! Much appreciated! We're still waiting on the tenant and client IDs and the secret.

A question about the deployment package, if I may? This sounds like a great solution. We never looked at this possibility yet until now. We tried to make a deployment package, but we only got through the first three steps. The other steps got a red cross. We're thinking it needs a storage space of some kind. Since we're on Azure, this is not there (yet). Does deployment package creation need to be done on a local development PC, working on a local code base by any chance? Or should it work on an Azure configuration as well?

Hi Alex,

The Deployment package process reuses the existing Creation steps to create a package. There are a couple of things that need to be set up prior to creating a package. More information on that here: https://docs.thinkwisesoftware.com/docs/sf/deployment_package

Summary; you'll need to update the "Generated scripts location” file storage location in IAM for the SQLSERVER_SF application (Software Factory). Here you can either specify a path were Indicium is allowed to write to. In your case, it could even be an Azure file storage. You are able to switch the File storage location type of the Generated scripts location. Again, Indicium needs to have sufficient rights to create folders and files within the specified path.

The Deployment package (2023.1) requires the previous model version to be named. The application you have in Production should have been created using a model version that has a name, e.g. V1. Within the sf_model_info table inside your end product, the model version is placed and should mirror that version name.

After that is indeed the case, you can set up data migration by reading the source version from the Production database. This will set the source version of the branch to be equal to the source version stored in the table inside your end product, effectively letting the Software Factory know what version the end product is. In case the model version does indeed exists, the source version is updated for you branch.

Once the data migration is set up correctly and any Upgrade scripts are in place, you can create a Deployment package. Now a package will be created in the specified Generated scripts location, which you can execute on the desired Production server for your end product. The Thinkwise Deployment Center can be used for that. It will make sure the application is upgrades to the newest version, e.g. V2. This corresponds to the given model version name that you have entered in the Create deployment package task. Also, this name is then recorded in the Model version table. 

Hope this is enough information 😄

Glad my reply helped out!

The situation you describe should work as far as I know. Our Support team can help better with this as they can dedicate time on finding out why the Deployment package is not working as it should. It can be as simple as that the source version of your branch was not set correctly prior to the Deployment package creation, I can’t be certain. Feel free to create a ticket 😄

Thanks again Mark! We'll create a TCP ticket if the next upgrade doesn't pull through. I'll report back here with the solution, if any, for future reference.