Published webservice returning error after DB restore
Hi guys, We have a published webservice for an Mx app running on client premises. This week the client restored the production DB into UAT so we could track a particular issue (not the webservice), and a third party that accesses the webservice and has been testing the WS in UAT server can no longer get a good response from the webservice. They keep getting the following error as response: <soap:Envelope xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <soap:Fault> <faultcode>Client</faultcode> <faultstring>LocalFileSystemStore:: File does not exist for key: 70a47a6c-b9ca-47f1-9e83-d93f88d0fe71</faultstring> </soap:Fault> </soap:Body> </soap:Envelope> The webservice is very simple, nothing odd to it, and it was working before the DB restore. I understand that could be some issues if the credentials of the webservice on live was different from UAT, but that is not the case, and they can certainly access/call the service, but why would we get this, almost null pointer kind of, issue? LR.
What Achiel is saying is that when creating a back up you create a backup of the database and a backup of all the file documents. From this error it looked like they did only restore the database. You have to unzip the filedocuments tar also and place the files in the deployment / data / files directory.
From the cloud you can retrieve three types of backups. The full backup, the database backup and the files backup. The full backup is a tar file containing two directories db and tree. The db contains the db.backup which is obvious the database. The tree file contains a lot more subdirectories. The objects in the subdirectories are the filedocument objects. The name of the objects ar something like 0a98a5c3-4d29-4cd3-a1b9-c0c3e2462097. They have no file extensions. If you know that the file is a pdf you could change the extension and just open the file. If you want your local database have the file document objects just copy all the subdirectories in the tree to the deployment / data / files directory.
For an on premise installation you need to copy the whole directory in the data folder of the Mendix installation to the new location.