Code Obfuscation

This is by design, code has always been obfuscated, it is now more completely obfuscated.   Custom code would not be, internal code remains obfuscated and requires support for in depth troubleshooting if need be.

That makes sense for protecting core IP, but it does raise a practical issue if the goal is for partners to develop and support extensions beyond simple integrations.

For partners writing extensions, I’d strongly suggest there needs to be a trust model that gives them enough visibility to diagnose issues properly. Otherwise, stack traces become very difficult to use, and every deeper troubleshooting issue has to go back through support, which slows everyone down.

I’m not suggesting all internal code has to be openly exposed, but there should be some mechanism for trusted extension partners to get meaningful debugging information when their work depends on the platform internals.

These do more than protect IP but also hide all internal APIs and internal objects.  Custom plugin code is not obfuscated and as such would show fully in the exception log for troubleshooting.   Any interaction internally is not.  Generally any exception completely originating inside internal APIs or stacks are non-actionable outside of Verint support or development as the code cannot be debugged and database access is not supported.   I am however happy to review any examples of situations that may differ from this.

These do more than protect IP but also hide all internal APIs and internal objects.  Custom plugin code is not obfuscated and as such would show fully in the exception log for troubleshooting.   Any interaction internally is not.  Generally any exception completely originating inside internal APIs or stacks are non-actionable outside of Verint support or development as the code cannot be debugged and database access is not supported.   I am however happy to review any examples of situations that may differ from this.

Please start with the errors that Rich Mercer @ 4 Roads has posted :) 

Search indexing errors are generally data related errors and require database queries to review, same would apply to an upgrade migration.  Both exceptions would appear to require Verint support.

It sounds like Verint Support is going to be very busy then, because this is one of the simpler migrations.  I thought the initial purpose of this forum was to provide pre-release support? 

To clarify, the exceptions are being reviewed, they should not yet go to support and be posted here.  As far as obfuscation is concerned it is a policy decision