Anyone else having any issues with editing existing SSRS Breaking\Routing Rules and are not able to open the Designer?
After being upgraded to Kinetic 2021.1 we received an error on a Scheduled SSRS Report that uses a Breaking/Routing Rule in System Monitor. Here is the error from the System Monitor:
Program Ice.Services.Lib.RunTask raised an unexpected exception with the following message: RunTask:
System.Xaml.XamlObjectWriterException: Cannot set unknown member 'Ice.Lib.Reporting.Model.RuleWorkflowStep.Next'.
at System.Xaml.XamlObjectWriter.WriteStartMember(XamlMember property)
at System.Xaml.XamlServices.Transform(XamlReader xamlReader, XamlWriter xamlWriter, Boolean closeWriter)
at System.Xaml.XamlServices.Load(XamlReader xamlReader)
at System.Xaml.XamlServices.Load(TextReader textReader)
at Ice.Lib.Reporting.Model.RuleWorkflowPersister`1.Load(String persistedInstance) in C:\_Releases\ICE\ICE4.1.100.0\Source\Shared\Lib\Ice.Lib.Report.Xaml\Model\RuleWorkflowPersister.cs:line 31
at Ice.Core.RptBase.ReportSsrsDatabaseBuilder.CreateWorkflow(ByteArrayCacheWithTemporaryBackingFile reportCache, Func`2 executeCommand, Func`2 executeReader, SqlObjectsCreated sqlObjectsCreated) in C:\_Releases\ICE\ICE4.1.100.0\Source\Server\Internal\Lib\TaskLib\RptBase\ReportSsrsDatabaseBuilder.cs:line 174
at Ice.Core.RptBase.ReportSsrsDatabaseBuilder.RouteAndBreakReport(Func`2 executeCommand, Func`2 executeReader, SqlObjectsCreated sqlObjectsCreated) in C:\_Releases\ICE\ICE4.1.100.0\Source\Server\Internal\Lib\TaskLib\RptBase\ReportSsrsDatabaseBuilder.cs:line 336
at Ice.Core.RptBase.ReportDatabaseBuilder.XMLClose() in C:\_Releases\ICE\ICE4.1.100.0\Source\Server\Internal\Lib\TaskLib\RptBase\ReportDatabaseBuilder.cs:line 93
at Ice.Core.RptTaskBase`1.XMLClose() in C:\_Releases\ICE\ICE4.1.100.0\Source\Server\Internal\Lib\TaskLib\RptBase\RptTaskBase.cs:line 198
at Ice.Core.TaskBase`1.StartProcess(Int64 instanceTaskNum, String outputFileName) in C:\_Releases\ICE\ICE4.1.100.0\Source\Server\Internal\Lib\TaskLib\TaskBase\TaskBase.cs:line 84
at Ice.Hosting.TaskCaller.InnerExecuteTask(IceDataContext newContext) in C:\_Releases\ICE\ICE4.1.100.0\Source\Server\Framework\Epicor.Ice\Hosting\TaskCaller\TaskCaller.cs:line 117
at Ice.Hosting.TaskCaller.ExecuteTask() in C:\_Releases\ICE\ICE4.1.100.0\Source\Server\Framework\Epicor.Ice\Hosting\TaskCaller\TaskCaller.cs:line 59
at Ice.Lib.RunTask.BpmFriendlyTaskLauncher.Run(String sessionIdPrefix, IceContext db, Action taskRunner) in C:\_Releases\ICE\ICE4.1.100.0\Source\Server\Services\Lib\RunTask\BpmFriendlyTaskLauncher.cs:line 63
at Ice.Services.Lib.RunTaskSvc.InnerRunTask(Int64 ipTaskNum, Boolean suppressTransaction) in C:\_Releases\ICE\ICE4.1.100.0\Source\Server\Services\Lib\RunTask\RunTask.cs:line 455
Per this error we thought we had a bad reference to a field or something in the Breaking/Routing Rule so we attempted to pull up the Designer to adjust and we received the following two errors and were not able to get into the Designer to attempt to make any changes:
Application Error
Exception caught in: System.ComponentModel.Composition
Error Detail
============
Message: The composition produced a single composition error. The root cause is provided below. Review the CompositionException.Errors property for more detailed information.
1) Cannot set unknown member 'Ice.Lib.Reporting.Model.RuleWorkflowStep.Next'.
Resulting in: An exception occurred while trying to create an instance of type 'Ice.UI.PrintRouting.Designer.Plugins.TakeAttachmentViewModel'.
Resulting in: Cannot activate part 'Ice.UI.PrintRouting.Designer.Plugins.TakeAttachmentViewModel'.
Element: Ice.UI.PrintRouting.Designer.Plugins.TakeAttachmentViewModel --> Ice.UI.PrintRouting.Designer.Plugins.TakeAttachmentViewModel --> AssemblyCatalog (Assembly="Ice.UI.PrintRouting, Version=4.1.100.0, Culture=neutral, PublicKeyToken=5d3fa3c7105d7992")
Resulting in: Cannot get export 'Ice.UI.PrintRouting.Designer.Plugins.TakeAttachmentViewModel (ContractName="Ice.Lib.WorkflowDesigner.WorkflowActionPluginBase")' from part 'Ice.UI.PrintRouting.Designer.Plugins.TakeAttachmentViewModel'.
Element: Ice.UI.PrintRouting.Designer.Plugins.TakeAttachmentViewModel (ContractName="Ice.Lib.WorkflowDesigner.WorkflowActionPluginBase") --> Ice.UI.PrintRouting.Designer.Plugins.TakeAttachmentViewModel --> AssemblyCatalog (Assembly="Ice.UI.PrintRouting, Version=4.1.100.0, Culture=neutral, PublicKeyToken=5d3fa3c7105d7992")
Program: System.ComponentModel.Composition.dll
Method: GetExportedValueFromComposedPart
Client Stack Trace
==================
at System.ComponentModel.Composition.Hosting.CompositionServices.GetExportedValueFromComposedPart(ImportEngine engine, ComposablePart part, ExportDefinition definition)
at System.ComponentModel.Composition.Hosting.CatalogExportProvider.GetExportedValue(CatalogPart part, ExportDefinition export, Boolean isSharedPart)
at System.ComponentModel.Composition.Hosting.CatalogExportProvider.CatalogExport.GetExportedValueCore()
at System.ComponentModel.Composition.Primitives.Export.get_Value()
at System.ComponentModel.Composition.ExportServices.GetCastedExportedValue[T](Export export)
at System.ComponentModel.Composition.Hosting.ExportProvider.GetExportedValuesCore[T](String contractName)
at Ice.Lib.WorkflowDesigner.WorkflowDesignSurfaceViewModel.GetAllPlugins()
Second Error:
Application Error
Exception caught in: System.Core
Error Detail
============
Message: Value cannot be null.
Parameter name: source
Program: System.Core.dll
Method: Where
Client Stack Trace
==================
at System.Linq.Enumerable.Where[TSource](IEnumerable`1 source, Func`2 predicate)
at Ice.Lib.WorkflowDesigner.WorkflowDesignSurfaceViewModel.FilterPlugins()
How complicated is this routing? Can you build a version from scratch without the error? If so, then it’s probably an upgrade issue and you (or Epicor) can compare the two versions to see what went wrong.
From the Preview it doesn’t look very complicated but I have no idea what the details are.
I did confirm that I can create a new Breaking/Routing Rule on another Report Style, so it’s something with the configuration, probably a field that was renamed or no longer part of the RDD or something (it is a custom RDD).
I have opened a Case with Epicor Support and I’m willing to wait a bit to see what they come back with in the short term.
Otherwise, I’ll have to do a bit more digging to determine what the details are of the workflow and rebuild.
Update: While waiting on Support I decided to Copy the Report Style (which includes the Breaking/Routing Rules) to save a copy for Epicor Support to troubleshoot and I then deleted and recreated the original as best as I could by reading the XML from a BAQ on the ReportStyleRules table.
It saved fine, I was able to edit it afterwards and when I ran the report through routing it did NOT give an error, so they might be out of the woods and the scheduled email.
However, comparing the XML of the two there are obvious differences in the structure and the rebuilt one was missing an element the original had which was something like 'RuleWorkflowStep.Next Action ="{x=null}"' and since that was also in the error message I suspect that’s the issue.
My guess is that the conversion script is missing something and not creating valid XML for the Rule.
The thing is the rule is not complex at all. a Break widget on one value (no sorts) → Condition for Yesterday and then an Email widget.
So if you have Breaking/Routing Rules upgrading to Kinetic… keep an eye out for issues.
Update from Support:
Issue replicated and submitted a PRB to development under PRB0234174
Dev has Accepted the PRB.
So there is likely a bug with Report Style Break/Routing Rules not upgrading from 10.2.700.12 to 2021.1
Hello Rick,
Our Epicor Pilot has upgraded to Kinetic 2021.1 and we have the same problem. We use report style ARForm (a system report style) to print and route invoices. The SSRS Breaking/Routing is very simple. There is a break for the InvoiceNum and e-mails are sent to the CustEMailAddress.
Similar to you, I can’t even open the Breaking and Routing Rule. My error message includes:
Cannot activate part ‘Ice.UI.PrintRouting.Designer.Plugins.TakeAttachmentViewModel’.
I am going to follow up with Epicare and also try to make a new breaking and routing as you have done.
Thank you for the post.
Sincerely,
Heide
Currently there is no scheduled release date for 11.1.200 according to EpicWeb; do you have a workaround for this that works now? Recreating the Break/Routing? Use Solution Workbench to install from Epicor 0?
I ended up Recreating the Breaking/Routing Rule.
I don’t know if installing an Epicor 10 Solution would work… perhaps, I didn’t try it as I did not have an other environment to work with.
Please do open an Epicor Support Case so the impact of this issue is documented with Epicor Support, sometimes it helps with getting issues resolved more quickly.
I wonder if it is due to having nothing connected to one of the Condition block outputs.
You say the XML from.the converted B/R had a part RuleWorkflowStep.Next Action ="{x=null}". Does the XML of the recreated B/R have a similar Next.Action part? If so, what is its value?
I had a similar thought… but I had never seen the workflow before, so I have no idea if whomever designed it had an orphan step or not. I know it’s common to leave orphan steps in BPM’s too (I do it all the time). Regardless, it should work… so hopefully Epicor will have this corrected on the next patch.
Luckily, taking a guess at how it should be designed worked. I haven’t had any complaints yet.
It doesn’t appear to have anything like that snippet. It almost looks like they changed how some of this works. I see things like 'RuleWorkflowStep.Action' and 'RuleWorkflowStep.NextNode' but nothing like 'RuleWorkflowStep.Next Action'
So my guess is that the conversion incorrectly converted the code or something.
Hello all! Let me provide a Epicor update on this. The primary reported issue is:
Problem: PRB0234174 (how support tracks it)
JIra: ERPS-160889 (how development tracks it).
Yes this issue is fixed ‘vNext’ already aka Kinetic 2021.2. However we recognize its importance and it is also fixed in Kinetic 2021.1.3 (11.1.100.3 for those looking at assembly versions).
For those who like to see under the hood: IN this release we removed some server properties and methods that had been marked as obsolete for most of the 10.2 timeline. IN this case we removed a ‘back’ property from the definition of an APR class that is serialized and stored in the DB. Sadly we missed in our regression testing that this would be a designer issue. AS this property was never used but is in the data we simply returned it as the quickest fix.