Hi All, I asked this question an hour ago and didn't get any response b

what you need to do is to compare the CDT UUID for the 2nd environment to the one that you are trying to import that the query rule reference. So to compare those you will need to export the application from the 2nd environment so you can compare it to the UUID that you get when you try to import the query rule and get an error.

ok I am not understanding what you are saying. I have a CDT in both environments verified and published properly. The problem comes when I try to import a query rule that references that CDT in the first environment to the second environment. I can get the uuid of the CDT when I do the inspection for importing it from first to second. But to get the uuid of the cdt in the second environment I tried to import it from second environment to first and the inspection was successful and so it didnt' show any uuid's in the inspection. So to solve that I thought you asked me to import the CDT from second environment to another 3rd environment and provide you with the import log.

so if I compare the CDT UUID in both environments they do not match which is why you are getting the error.. I suggest you open a support ticket because there is an issue with the UUID's not matching

I cannot get the UUID of the CDT in the second environment because the inspection is successful when I try to import it to first environment and 3rd enviroinment and I don't have any more environments to play with.

Then I think the best suggestion is to contact support for more assistance..

SUGGESTION:

1. Open the DCMIFS_getREGDocType
2. Remap it to the entity in your data store
3. Re-export the app (make sure to include both the query rule and the data store)
4. Try the import

If that still fails, here's how you can get the UUID and confirm whether the two data stores are in sync

SET OF STEPS #1

1. Login to environment A (SOURCE ENVIRONMENT: Where you exported the problematic query rule from)
2. Create a simple application and export ONLY the DATA STORE that this query rule uses.
3. Export the application and download it
4. Unzip the application
5. Open the DATA STORE xml insider <ZIP_FILE>\\dataStore
6. The entities are listed there with NAME and UUID. Find the UUID used by the Query Rule DCMIFS_getREGDocType

Here's an example of an entity called Student, the uuid is the alphanumeric string in the <uuid> element

<entity>
<uuid>8f670a0a-ab1d-427f-8b43-a79f482ab6ea</uuid>
<name>Student</name>
<type>{cnu230062w.appiancorp.com:8080/.../type>
</entity>



SET OF STEPS #2

1. Login to environment B (TARGET ENVIRONMENT: Where you are trying to IMPORT)
2. Create a simple application and export ONLY the DATA STORE that this query rule uses.
3. Export the application and download it
4. Unzip the application
5. Open the DATA STORE xml insider <ZIP_FILE>\\dataStore
6. The entities are listed there with NAME and UUID. Find the UUID used by the Query Rule DCMIFS_getREGDocType


STE OF STEPS #3

Compare the UUID of the entity from step 1.6 and 2.6. You will realize they are different.

Why would this happen? Well, this happens because when you create Data Stores you can add entities inside, those entities have a name and a UUID. If you delete an entity and re-create it (same name), since this was a deletion, your re-added entity gets a new UUID therefore it no longer matches what the query rule was pointing to.