Customer managed Azure SQL
The following section contains information for customers with an SLA3 agreement where the customer will store the storage tables in their own Azure SQL database.
The customer understands and agrees that the customer is solely responsible for all maintenance, up-time, backup, performance, security, and any other issue related to this customer Azure SQL database and how it affects their overall Aimplan solution.
The current Aimplan SaaS service for Europe is running in Azure Norway East. It's recommended that the customer Azure SQL database resides in the same location or as close as possible to decrease latency between the Aimplan SaaS service and the database.
Which Azure SQL tier to select very much depends on the use case. If the use case is only to manage master data using the Aimplan Data Input table visual, the requirements on the Azure SQL is low. But if we talk planning and forecasting using the Aimplan Planning and Reporting visual the overall performance is very much depending on the performance of the underlying Azure SQL database.
We recommend at a minimum an Azure SQL standard S2 with 50 DTU. If the size of the planning and forecasting data is > 1M records, we recommend leveraging column store index technology which today requires a S3 configuration.
The advantage with using Azure is that you can easily try out different configurations and compare performance. You can also scale up-and-down depending on workload.
Note that using your own Azure SQL is not the default. If using the Aimplan SaaS service, the default is that we store the data for you using our Azure SQL SaaS infrastructure.
The server and name of the database doesn't matter. You could even use an existing Azure database that you already have in place. Aimplan will be able to work only against special tables configured in a specific way, separated in a named schema within the database.
When you sign up for the Aimplan SaaS service you will receive an 'Instance-Id'. It's start with an "I" and contains 4 numbers. For example "I0007".
Every script below contains <xxxx>, eg. CREATE SCHEMA I<xxxx>DAT. You must change <xxxx> with your instance number. Please note that only numbers should be inserted, e.g. CREATE SCHEMA I0007DAT.
[@PASSWORD1] and [@PASSWORD2] should be replaced with a 20 characters strong password. e.g. CREATE USER I<xxxx>DAT_O WITH password = '[@PASSWORD1]' should, if your instance number was 0007, be changed to CREATE USER I0007DAT_O WITH password = 'seu%2=2390!#38dsr+1@'Please note that this password is only an example, do not use this password!
CREATE PBI and DAT schema
Create the DAT_O user
Create the DAT_RW user
Create the PBI user
Send the information to us
When schemas and users are added we need to know the following:
- Your server name (tcp:<servername>.database.windows.net)
- The database name where you created the schemas and users
- @PASSWORD1 and @PASSWORD2
Do not send any e-mail containing the passwords. Contact [email protected] and agree on a method to deliver this password to Aimplan for configuration. This login information will be stored encrypted in Azure. The user accounts you just created will also only have access to these specific tables.
Even if running your own Azure SQL database, there will still be some Aimplan system tables that will reside within the Aimplan Azure SQL hosting environment. These are the tables that are not 'Storage Tables'. This means that fixed system tables such as Users, Scenarios, Measures, and metadata tables regarding StorageTables are still stored within the Aimplan database. You will have read access from Power BI to the data in these system tables.
But with an SLA3 agreement, the storage tables that you design yourself and that will store your specific data will be stored in your own Azure SQL database.