Skip to main content

Hi everyone,

We have one SF that we use to deploy (create) to a development environment and an environment for testing and user acceptance. This is set up in Azure environment 1. We are in the process of setting up the production environment. This is Azure environment 2. The production environment will have its own IAM and an application.

The IAM database is created and set up in the production environment (Azure#2) by means of the Deployment Center. Also, Indicium and Universal have been set up in an app service on Azure#2. appsettings.json has been provided with the correct (pool) user data and database name. This user has verified access to the database. The next step would be doing a creation from the SF on the development environment (Azure#1) to the production environment (Azure#2).

The SF offers an option to configure a custom pool user for a runtime configuration. However, this option is greyed out and read only for us. The pool user for the development environment (Azure#1) has the same name as the one for the production environment (Azure#2). The password is, of course, not the same. Also, the password for the production environment is administered by a third party. We have no way of changing this easily.

When we make a connection to the production environment from SF's Functionality section, we get a successful log on. Username and password can be provided here. This works. But we cannot seem to do a creation to the production environment using the credentials for the production environment (Azure#2).

The Docs section doesn't discuss an actual creation like this. Docs tell about IAM and Indicium/Universal, but not about how to deploy the application itself. How do we do this, without availability of the option to set a custom pool user for the runtime in SF?

Regards,
- Alex.

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 😄

Everything worked out as you described, Mark. Thank you! We locked horns with the Azure storage, because it refused to save the package until we figured out that both the runtime configuration in SF and the application storage in IAM need to have the same SaS token. It's not sufficient to configure both with a valid but different token.

We have an additional question though. We gave the deployment package a version, as you said. After deployment package #1 we kept on building, and created a deploymnt package #2, with a different version name/number. However, Deployment Center refused to update the installation that we did using deployment package #1. Instead, we used deployment package #2 to create a new application, and deleted the previous one.

How do we get the deployment package to update the installation in the future? We tried changing the manifest file (set the supportedVersions key) to accept the previous version, but it didn't work. Deployment Center said "no" to the upgrade. The client will start using the application next week. We can't resort to creating a new application anymore. What are we missing?

Best regards,
- Alex.

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.

Terms & ConditionsCookie settings