When I started the server in guidewire CC I got this error.
com.guidewire.pl.system.exception.UpgradeException: Encryption has been removed or changed, but the OldEncryption plugin is not defined. Please see your documentation for details on encryption upgrade.
Please help me to resolve this error.
This exception happens when ClaimCenter detects that you have changed encryption schemes without properly leaving the old plugin registered.
You can have multiple plugins which implement the IEncryption interface.
Lets say you're using SHA1 encryption registered through a SHA1Encryption.gwp Plugin Registry:
<plugin
interface="IEncryption"
name="SHA1Encryption">
<plugin-gosu
gosuclass="com.mycompany.plugins.encryption.SHA1EncryptionPluginImpl"/>
</plugin>
And configured in config.xml:
<!-- The name of the current encryption plugin. -->
<param name="CurrentEncryptionPlugin" value="SHA1Encryption"/>
Then you decide to switch to AES encryption.
You first have to create a new Plugin Registry file AESEncryption.gwp:
<plugin
interface="IEncryption"
name="AESEncryption">
<plugin-gosu
gosuclass="com.mycompany.plugins.encryption.AESEncryptionPluginImpl"/>
</plugin>
Then you have to modify the config.xml to tell ClaimCenter to use the new Plugin:
<!-- The name of the current encryption plugin. -->
<param name="CurrentEncryptionPlugin" value="AESEncryption"/>
Do not remove the SHA1Encryption.gwp Plugin Registry.
ClaimCenter keeps track of the Encryption Plugin used to encrypt each record, by NAME of the Plugin Registry file. If it can't find the file, you will get this error.
ClaimCenter is also capable of detecting that the implementation class has changed even if the plugin name hasn't (metadata change). In that case, it looks for a Plugin Registry named OldEncryption.gwp.
If it can't find the specific name, AND can't find OldEncryption.gwp, then you will get this error.
More information can be found in the Integration Guide from Guidewire.
Sounds like the database you are connecting to is a newer or differently encrypted version that what the Guidewire application codebase you are running is expecting.
What is the value of CurrentEncryptionPlugin in your config.xml file?
<!-- The name of the current encryption plugin. -->
<param name="CurrentEncryptionPlugin" value="AESEncrypter"/>
I found this was due to my not having the extensions.properties file updated to the latest number. To fix:
Hit Cntl-Shift-n
Search for "extension.properties"
Go into the file and change the number to the appropriate number
Save
Restart Guidewire Studio
I was set after I did this.
Easy way to pretend this type of exceptions,
change the DB path from database-confix.xml
Open extension.property file
content of the file will be like
version=34
increment the value of version by one, if you had made changes in any of the existing table structure
Restart the server
Whenever will get this UpgradeException, the newer upgrade version number shows in console along with old version number. You have to update the new number in
the extension.property file.
Related
I have created 3 independent MSI files using WIX3.8
The first MSI package is the core package which installs the basic(Core) components.
The other two MSI packages are add on to the first MSI. I have put the necessary checks in place which will prevent a user from installing the add-ons if the basic components are not installed.
The problem now is how do I prevent the user from un-installing the core components when the add-ons are installed?
I have added specific registry keys while installing each MSI so that I can refer them.
I have spent over 2 days on Google and SO but could not find any solution :(. If I missed anything please provide me the reference link.
Any help is greatly appreciated.
Use the Upgrade element with the other addon components upgrade codes to detect the other products.
E.G. In your core components installer add something like
<Upgrade Id ="Addon Product A's Upgrade GUID">
<UpgradeVersion OnlyDetect="yes" Minimum="0.0.0.0" Property="ADDONADETECTED" IncludeMinimum="no" />
</Upgrade>
<Upgrade Id ="Addon Product B's Upgrade GUID">
<UpgradeVersion OnlyDetect="yes" Minimum="0.0.0.0" Property="ADDONBDETECTED" IncludeMinimum="no" />
</Upgrade>
<Condition Message="There are other products that depend on these components, aborting uninstall.">
<![CDATA[ADDONADETECTED OR ADDONBDETECTED AND (NOT UPGRADINGPRODUCTCODE) AND (REMOVE="ALL")]]>
</Condition>
I would:
Add ARPSYSTEMCOMPONENT to those MSI files so they don't show in Programs&Features.
Assuming you allow normal major upgrades, make the bundle do the uninstall with a command line parameter such as BUNDLEUNINSTALL=1 and then have a type 19 custom action that prevents the uninstall from continuing if REMOVE="ALL" AND BUNDLEUNINSTALL<>1.
I'm not sure that a registry search provides a good solution. I would use a custom action based on MsiEnumRelatedProducts (upgradecode of other products using these components) to find the ProductCodes of those products. If you get some ProductCodes back then you can call a type 19 custom action to prevent the uninstall. In general Rick's suggestion is good, but I think the strategy you should go for is to use a bundle. This kind of thing: http://wixtoolset.org/documentation/manual/v3/xsd/dependency/provides.html
I just attempted to update the site map provider from 3.3.6.0 to 4.0.14. I followed the instruction on the wiki however my SiteMapPath now renders empty. I made no changes to the mvc.sitemap file other than updating the schema to 4.0. When I debug into the SiteMapPathHelperModel I find that the model has no nodes defined. I am using the internal DI container (I would like to get this working before switching over to the application container).
When I check the sitemap.xml file it is well populated which makes me think that the mvc.sitemap is being read.
I'm out of ideas on this one and would be happy to provide any additional information which may be useful. I'm not even sure where I can hook into debug this problem. Literally the only thing I changed between a working 3.3.6.0 and a not working 4.0.14 was what was prescribed on the wiki.
Ok, since your /sitemap.xml endpoint appears to be working, you are correct the sitemap is being populated and loaded correctly.
There are a couple of things I know of that can cause this to happen:
If you are using Dynamic Node Providers, they must be added to a node that is not otherwise part of the sitemap. See my question here - I am trying to figure out why this is the case as well.
Your routes don't match your nodes - please read Routing Basics and/or post your routes and Mvc.sitemap XML.
If you check the above and everything appears to be correct, please make a small demo project showing a sample of your configuration and open an issue on GitHub, as it is highly likely your specific configuration has something to do with the problem.
BTW - You can debug by cloning the current repo on your system or downloading the solution as a zip, enabling NuGet package restore on your solution (right click the solution > Enable NuGet Package restore), add the MvcSiteMapProvider project to your solution, and then in your project remove the reference to MvcSiteMapProvider and add the reference to the newly added MvcSiteMapProvider project from your MVC project. Then you can add breakpoints and step through the code. I suggest making a backup of your solution (or ensure you can roll back another way) before doing this, and reverting back to your current state when done.
I have documented the whole procedure here: http://www.shiningtreasures.com/post/2013/08/21/debugging-an-mvcsitemapprovider-configuration
I have somehow got into a strange situation with my CRM system.
A plugin I have developed is not getting updated correctly when the solution is imported. When I choose to maintain the customisations the plugin updates dont get applied, but when I choose to overwrite customisations the steps get doubled up and so the plugin gets fired twice.
Has this happened to anyone else? How do I stop this from happening?
Thanks
I've had a similar situation where I had plugins registered twice after importing.
I believe the way I solved this was:
Use the plugin registration tool to remove the plugin from the server you are deploying to.
Reimport the solution.
I can't see you doing any major damage here, but I would suggest backing up the server first because I'm not 100% on this one.
Are you assigning a strong name to the assembly? I've seen this kind of thing happen in CRM 4.0. If you don't assign a strong name with a key, CRM doesn't seem to see that it is the same assembly.
If you deploy the plugins using the plugin registration tool, solution deployment will duplicate all of the steps as it does not recognise the deployed plugin steps as their ID is changed.
If plugin assembly is deployed without the steps, you've forgotten to add the steps into the "Sdk Message Processing Steps" section of the solution.
#JamesWood approach will always work but is very heavy handed for a production environment, an IIS Reset and restart of the MSCRM services (in services.msc) usually clears any cached plugin assembly, while a redeployment should only be needed/used in dire situations.
I am deploying my project from sandbox to production. And i am using "ANT" tool for deploying. But it is giving me error as given below:
Error: objects/Form__c.object(144,13):field integrity exception:
unknown (must specify either cascade delete or restrict delete for
required lookup foreign key)
Can anybody help me please.
Thanks,
Goto line no 144 of your object Form__c there will be a Lookup Field , in that field remove the 'Required' Tag , remove that tag completed and start your ant deploying again.
Sounds like an API version mismatch thing. If I recall correctly ability to reparent master-detail relationships and to mark lookups as required on DB level instead of layout level was introduced in summer'12. Your XML file is coming from sandbox without this feature so SF is complaining at the missing tags.
See release notes (pages 183-184), though they don't really mention the metadata changes...
I am working on a cloud application. When I test out the application on my computer I want to have my connection string set as follows in ServiceConfiguration.cscfg:
<Setting name="DataConnectionString" value="UseDevelopmentStorage=true" />
When I publish to the cloud I need to have it set as follows:
<Setting name="DataConnectionString" value="DefaultEndpointsProtocol=https;AccountName=xxxx;AccountKey=yyy" />
I keep going from one environment to the other and keep having to change the DataConnectionString.
Is there a way that I can automate this? I looked around and can't see any examples but I'm sure some others have the same problem as me.
Thanks,
Nancy
I've answered a similar question here:
Visual Studio 2010 can apply Debug or Release transformations to Web.config, but what about the Azure settings?
While Igorek's approach works perfectly we prefer to make such kind of transformations on our CI server which is also responsible for automatic deployment. The main reason is to restrict access to sensitive data, since only limited number of trusted developers have access to CI server. Also, it helps to keep our code cleaner, since it doesn't include redundant config project. In our case we use Hudson-CI (Jenkins-CI) and MSBuild.ExtensionPack.FileSystem.File (replace action) to transform config files.
In the part of your code that gets the connection string, you can use the #if(DEGUG) preprocessor directive in order to use something or not depending if the compilation is Debug or not, or the if(Debugger.IsAttached) (MSDN) in order to know if the debugger is attached.
You can use CloudConfigurationManager in Azure SDK 1.7 http://msdn.microsoft.com/en-us/LIBRARY/microsoft.windowsazure.cloudconfigurationmanager
This starts by looking in the ServiceConfiguration.cscfg e.g. ServiceConfiguration.Cloud.cscfg for config setting. If it isn't there it falls back to web.config and app.config
For example
CloudConfigurationManager.GetSetting("StorageConnectionString")
Will look in the appropriate cscfgfile for StorageConnectionString setting, then it will search the web.config and then app.config.