So they provide a zipped subfolder and I know that I might need to deploy this data in a proper subfolder to align the scopes.
BUT: sometimes I face a behaviour I didn't understand but which was explained to me by some colleagues today. In my case I thought to have a proper deployment but my "listDIstanceMatrices" did not return the matrix I was looking for. Now here's a list of potential reasons in the xDIma2 context!
- The dima.ini contains a key NETPATH that has to match the current mapPath configured in xserver.conf
- The dima has to be "valid": this is shown to the server by an existing "dimaname".valid file. If that file is missing the dima is excluded from the server. I just created another dima on that server, copied and renamed it's "valid" file.
- The trickiest one: Part of the dima is the underlying routing profile (RoutingProfile.xml). The routing profile file has to match the xServer2's current version! In my case I received a dima that has been created on v2.26. I tried to deploy it in v2.28.1. Between these two versions we changed some names of some experimental routing profile parameters (mainly energy / emission ...). So I had to replace the profile given by the customer with a dummy profile from the current server
Bernd
PS: on top of that: the default setting for "core.distanceMatrixGarbageCollectionEnabled" in xserver.conf is true. This deleted my customers dima subfolder because I hadn't copied the ".valid" file into the subfolder.