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

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.

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.