The following error might occur when you run an installable cloud app: Session creation failed.
Cause:
-
The Web APIs has not been deployed to the specified website or the Web APIs has not started.
Solution: Make sure the Web APIs has been deployed and started.
Take the URL in the above error as an example, you can input http://localhost:5001/health-ui/ to verify the Web APIs can start successfully. If the page displays successfully, then the Web APIs has been deployed and started, otherwise, you will have to deploy and start the Web APIs.
-
The Web APIs is not on the same server as the client app.
Solution: If the Web APIs is not on the same server as the client app, then you cannot use "localhost"; you should use the IP address or host name of the server hosting Web APIs.
-
If the host server connects to Internet via a proxy server, then PowerServer Web APIs has to be configured with the proxy server as well.
Solution:
Open the PowerServer Web APIs > UserConfig.json file, and configure the proxy server settings in the "ProxyOptions" block. The password for the proxy server (if any) must be an encrypted value (encrypted by the CustomizeDeploy.dll tool).
... "ProxyOptions": { "Server": "", "Username": "", "Password": "" }, ...Publish the PowerServer Web APIs to the server.
-
The version of ASP.NET Core Hosting Bundle does not match with the version of .NET framework used by Web APIs.
Solution:
Download and install ASP.NET Core Hosting Bundle.
Error:
Cause 1 & solution:
The Web API URL is incorrect. Please double check and make sure
-
There is no redundant sub-directory in the URL. When PowerServer Web APIs is deployed to IIS, the Web API URL is usually the site URL or the sub-app URL.
If you place the compiled Web API files (including the app executable file ServerAPIs.exe, app assembly files, dependencies, web.config etc.) directly in the IIS Web root, the site URL = the Web API URL, such as "http://172.16.100.2:83/".
If you place the compiled Web API files in a sub-folder under the IIS Web root, and then convert the sub-folder to sub-application in IIS, then the site URL + sub-folder name = the Web API URL, such as "http://172.16.100.2:83/googlecharts_cloud_API/".
If you place the compiled Web API files in a sub-folder under the IIS Web root, and the web.config file in the web root points to ServerAPIs.exe in this sub-folder (such as ".\salesdemo_cloud_API\ServerAPIs.exe"), then the site URL = the Web API URL, such as "http://172.16.100.2:83/".
-
There is no redundant slash ("/") after the port number in the URL. Correct: http://172.88.88.88:5000/.... Incorrect: http://172.88.88.88:5000//....
Cause 2 & solution:
If using IIS and the web.config file, make sure 1) the web.config file exists under the web root or app base path; and 2) the handler path in the web.config file is incorrect.
If you have created a new site (or sub-app), mapped the new site (or sub-app) to an existing site where web.config and Web APIs are deployed, and specified the URL of the new site (or sub-app) as the Web API URL, then you must also make sure the handler path includes the new site (or sub-app).
For example, you may have to change the path from the default
<handlers>
<add name="aspNetCore" path="/api" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
<add name="aspNetCore2" path="/health-*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
<add name="aspNetCore3" path="/connect/token" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
</handlers>
To
<handlers>
<add name="aspNetCore" path="/powerserver/ReportApiExample/api" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
<add name="aspNetCore2" path="/powerserver/ReportApiExample/health-*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
<add name="aspNetCore3" path="/powerserver/ReportApiExample/connect/token" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
</handlers>
The leading forward slash (/) indicates the root of the website, and the directory or virtual directory name is specified thereafter.
Error:
Cause 1:
Two applications under the same IIS website cannot use the same application pool.
Solution 1:
Step 1: Configure the two Web APIs to use different application pools. (Refer to this section for how to create and configure the application pool.)
Step 2: Restart the website.
Step 3: Double check that the Web API URL includes the API sub-folder name. (Refer to this section for detailed instructions.)
Cause 2:
The Web APIs failed to work because some dependency files are mismatched.
Solution 2:
You can try to run Web APIs in the development environment to determine the cause, by following instructions in Figuring out if the deployed Web APIs can run at all.
Cause 3:
This error is caused by the server-side error.
Solution 3:
You can check the following log files:
-
Check the PowerServer log (\Logging\logs\powerserver.log by default under the API folder).
To output more detailed information to the log file, you can change the PowerServer log level. For more, refer to Logging with the settings in Logging.json and Configure log settings.
-
Check the system Event Viewer on the server machine.
-
(If using IIS) Check the IIS log file (usually located in %SystemDrive%\inetpub\logs\LogFiles).
Error:
And you will see the following error in the Windows event log:
Cause
The most common cause for this error is that the Web API is published for an incompatible processor architecture. For example,
IIS is running as 64-bit while the Web API was published to target 32-bit; or
IIS is running as 32-bit while the Web API was published to target 64-bit.
Solution
To resolve this error, you can change the bitness of either IIS or Web APIs:
-
Solution 1: Change the setting of "Enable 32-Bit Applications" in IIS.
Detailed steps: in IIS Manager, select Application Pools in the Connections panel. Select the app's application pool. In the Actions panel, select Advanced Settings. Change the setting of Enable 32-Bit Applications.
If Web APIs is 32-bit, set Enable 32-Bit Applications to True so IIS runs as 32-bit; if Web APIs is 64-bit, set Enable 32-Bit Applications to False so IIS runs as 64-bit.
-
Solution 2: Republish the Web API for the same processor architecture as IIS.
Detailed steps: Go to the PowerServer project painter > Deploy page > Basic tab. If the Framework mode is set to Self-contained, make sure the Target runtime is set to the same processor architecture as IIS. And then build and deploy the project again.
-
Solution 3: Publish the Web API as a framework-dependent deployment.
Detailed steps: Go to the PowerServer project painter > Deploy page > Basic tab. Set the Framework mode to Framework-dependent, make sure the Target runtime is set to Portable or the same processor architecture as IIS. And then build and deploy the project.
Error:
Cause & solution:
If you have implemented authentication in the application, please make sure the authentication server is running normally and the application can work with the authentication server.
Error:
Cause:
The host name of the Web API does not match with the host name in the SSL server certificate. For example, if the server certificate is a self-signed certificate which works for "localhost" only, then you cannot use IP address or domain name in the Web API URL; you can only use "localhost" in the Web API URL.
Solution:
Make sure the host name of the Web API matches with the host name in the server certificate.
In the local development environment, if a self-signed certificate is used, you can change the Web API URL to use "localhost" instead of IP address or domain name; or if you want to use IP address or domain name, you can consider selecting the Whether to ignore server certificate option to ignore the error. For more, refer to Support HTTPS.
In the production environment, you should create a trusted CA signed certificate (instead of using a self-signed certificate).
