Troubleshooting

Some issues solutions

Mobilize’s Azure Registered App

For this web service to work correctly, an associated registered azure application from Mobilize’s portal needs to have currently valid certificates. When not valid anymore, the web service is not going to be able to authenticate for azure usage, and it may difficult to debug or encounter where this registered application is. As of now, the aforementioned can be located here. The client-id and tenant-id should be easily located at the top of the information panel, they SHOULD MATCH the client and tenant id in the DB Manager code. If the certificates are invalid, also at the top of the page, a message should appear saying so. A new secret code is needed for the certificates to be valid again, so a contact to the DevOps team explaining the issue could be in order. If needed, when renewed, the new secret key should be changed in DB Manager’s code.

Neo4JRegistry

Another possible point of failure could be the access and secret keys for the Neo4J Registry app, which is the one in charge of mounting the containers holding the databases for the different uses they have. The container registry can be found here. In the left panel, the access keys will be found, those are the ones used by the DB Manager in the CreateACI function. The keys must match the ones in the code.

Publishing Know-How

If in need to publish the DB Manager service, there are some factors one should account for in order to ensure the correct behavior of the previous work.

First, take a look at the kudu debug console for the DB Manager service, most importantly; this is where to find the “filesystem” associated with the service and the files it needs. One of the most important folders will be inside “D:\home\site\wwwroot\” and its name is neo4j. As its name may have let you know, files related to neo4j’s database “engine” are located here, to be more precise; the whole folder containing Neo4j Community Server in version 3.5.18 is dumped in this folder, if it does not exist, then API calls like to create a database will fail. Conveniently, the loggers used throughout the project are also in this folder; inside “neo4j/logs/”. That is the perfect place to go see what the service is doing with the API calls, if any exception is thrown in execution, the normal behavior would be for the logger to produce output about it in a folder with the current day of execution as name; this is obviously assuming that the service was able to catch the exception, if not it may be more difficult to debug. As it is expected that this folder exists, then when publishing there are two options that may be done to maintain current (normal) behavior:

• Check the publishing options and make sure the option to delete prior files is unchecked as this will delete neo4j’s folder, remember this folder is not part of the project itself, so Visual Studio will flag it as an unused folder.

• If you need to delete prior files for whatever reason, then go to the kudu debug console of the service, go to the route “D:\home\site\wwwroot\” create a new folder called neo4j and dump all files from the Neo4J Community Server version 3.5.18 in the newly created folder. Make sure you are dumping the Neo4J files in this folder and not another folder containing them, that is; make sure you have a structure like “D:\home\site\wwwroot\neo4j\bin” and not something like “D:\home\site\wwwroot\neo4j\another_folder\bin” as that will not work either.

API Calls and Errors

There are two nice options to try the API calls, one is the DBManagerCLI console application in the DB Manager project and the other one is an API tester such as Postman. The console application may be easier to use and a more direct approach, but sometimes it is useful to run a request, manage the parameters oneself, and see exactly what the response is, this is where Postman and such become a great help.

The worst case of failure would be to get a 500 Internal Server Error to an API call, this would mean clearly the service ran into an unexpected error, as mentioned before; the first step would be to go to the kudu debug console and look for the log files, analyze the service’s behavior and see if there are some hints about the abnormal behavior. If not, then try to run the web service locally, do not try to run the API calls (they probably will not run nicely), but watch closely how the service goes to upstate, and how it behaves with the azure connection, anything related to neo4j WILL fail, as it is expecting to be run in the cloud’s environment.