Within one of our Appian instances we are getting the 'Illegal attempt to ch

Please review: forum.appian.com/.../Customizing_Application_Logging.html

There is no utility to completely remove a plug-in. Removing the plugin from <APPIAN_HOME>/_admin/plugins will uninstall the plug-in but it won't remove the CDTs created by it.

The case 410893 has been created to follow up on this issue.

Thanks. I understand that uninstall doesn't remove the CDTs created by the plugin and that these can be "removed" manually within data management. The intent of the question was simply to find out if such a utility existed. Thanks for the reply. Are you aware of any logging we can turn on to show us exactly what Appian thinks is different about the parameters? This will help us debug the problem further.

With the property I gave you, you will be able to review the XSD being generated by the plug-in. Then you can compare it with the current one in your environment.

Please provide the server.log following the instructions I provided in the case.

Keep in mind that deleting a CDT deployed by a plug-in under the Data Management Tab would cause the issue you're seeing. CDTs created by a plug-in shouldn't be deleted unless you are really going to make a chance to them.

This is because:

1. When your first register your plug-in Appian registers it as a smart service with an input of type MY_CDT

2. When you delete a CDT the original version is deprecated and renamed to MY_CDT^1 but the local ID remains the same

3. At this point internally Appian knows your plug-in uses a node input of type MY_CDT^1 (the original CDT)

4. You later decide to re-upload the CDT with changes or without. This results in a new local ID assigned to the current version of the CDT called MY_CDT which is different from the original ID of the CDT now called MY_CDT^1

5. When you restart the application server Appian reads the annotation in your smart service and sees that you indicate the smart service references MY_CDT, but remember MY_CDT is now the latest version which has a different local ID. Appian then checks what it registered in step #1 and confirms that originally the smart service was configured to use the local ID of MY_CDT^1 (which back then was called MY_CDT) but now you're trying to deploy it to use MY_CDT with a different local ID.

Assuming the deletion wasn't intentional the workaround is to annotate your plug-in to make it point to MY_CDT^1

          @Input(required = Required.ALWAYS)
          @Name("myInput")
          @Type(namespace = "types.appiancorp.com/ps", name = "MY_CDT^1")

Thanks for the reply and the reminder. This makes sense. Unfortunately, we don't know how we originally got into the situation. I don't believe anyone manually or purposely deleted the CDTs, nowever it is an avenue to research further. At this point however, the CDTs have been deleted once since originally encountering the problem,since all other efforts failed to resolve the issue.

So a couple follow-up questions...

1. Since it isn't possible to delete all references to a plug-in in Appian (even if it isn't used) so that we can redeploy it successfully without changes to the plugin, is it possible through Appian or an API to get a list of the plugins deployed in Appian, along with their CDT parameter version numbers, so we can attempt to annotate the plugin with the proper versions so we can perhaps deploy them without changing the key?

2. Assuming this situation has happened in a new envrionment which has a complex intial setup and configuration, is there a way to restart Appian with fresh data (as if it was a new installation) so the plugins will deploy, without having to go through the entire installation and setup process again?

1) This feature is available in Appian 7.7 an above:

forum.appian.com/.../Appian_Administration_Console.html

However, this feature only shows the CDT name, not the version.

2) You would require to delete the kdbs, use a new datasource and some elements of the _admin directory. To avoid any unexpected file deletion, we recommend you to create a fresh install.

Just as a side-note when the issue occurs the annotation will always be of type ^1 because if the CDT is included the plug-in we can be completely sure both were deployed for the first time meaning the input is associated with the first version of the CDT. I'm not saying there cannot be cases where ^X (with X > 1) might be needed but it's unlikely.

Do you know if there is any new functionality to remove the CDT's created by a plugin?

No changes in the product on this feature. The solution is still to use the annotations and to instruct developers not to delete the CDTs that plug-in use.