Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
We have multiple qlik environments in prod and i am checking if we can use the same service IDs
1. across multiple qlik sense and qlikview environments
2. across multiple qlik sense environments only
Do you see any issues with the above? I would prefer to have the same service ID across all qlik sense and qlikview environments as it is easier for maintenance and updates.
I am using a different service ID for nprint since i believe using the same ID as qlik sense will cause issues.
Hello @srik00001
The feasibility of using the same service IDs across multiple Qlik environments depends on the architectural setup, usage, and security requirements of your organization.
Across multiple Qlik Sense and QlikView environments: Qlik Sense and QlikView are different products, and they are usually set up and administered separately, even though they can share some back-end components like Qlik's associative data engine. Depending on your setup, using the same service IDs across both could be technically possible, but it might complicate matters if there's an issue that only affects one service. In terms of security, it's generally best practice to use separate credentials for separate systems to minimize the potential impact if one system is compromised.
Across multiple Qlik Sense environments: This would generally be more feasible than using the same service IDs across both Qlik Sense and QlikView, especially if the environments are similar. However, similar considerations apply: if there's an issue with one environment, it could be more difficult to troubleshoot if they're all using the same service ID. And from a security standpoint, using separate service IDs would still be more secure.
As for NPrinting, you are correct that it's best to use a different service ID. NPrinting is a reporting platform for QlikView and Qlik Sense, and it has different requirements and settings. Using the same service ID as Qlik Sense could lead to conflicts or issues.
So in general, while it might be possible to use the same service IDs across multiple environments, and it could potentially simplify some aspects of administration, there are also potential downsides in terms of troubleshooting, security, and risk of conflicts. You would need to carefully weigh these factors based on your organization's specific needs and constraints.
Hello @srik00001
The feasibility of using the same service IDs across multiple Qlik environments depends on the architectural setup, usage, and security requirements of your organization.
Across multiple Qlik Sense and QlikView environments: Qlik Sense and QlikView are different products, and they are usually set up and administered separately, even though they can share some back-end components like Qlik's associative data engine. Depending on your setup, using the same service IDs across both could be technically possible, but it might complicate matters if there's an issue that only affects one service. In terms of security, it's generally best practice to use separate credentials for separate systems to minimize the potential impact if one system is compromised.
Across multiple Qlik Sense environments: This would generally be more feasible than using the same service IDs across both Qlik Sense and QlikView, especially if the environments are similar. However, similar considerations apply: if there's an issue with one environment, it could be more difficult to troubleshoot if they're all using the same service ID. And from a security standpoint, using separate service IDs would still be more secure.
As for NPrinting, you are correct that it's best to use a different service ID. NPrinting is a reporting platform for QlikView and Qlik Sense, and it has different requirements and settings. Using the same service ID as Qlik Sense could lead to conflicts or issues.
So in general, while it might be possible to use the same service IDs across multiple environments, and it could potentially simplify some aspects of administration, there are also potential downsides in terms of troubleshooting, security, and risk of conflicts. You would need to carefully weigh these factors based on your organization's specific needs and constraints.