I've written a custom workflow activity against CRM 2013. You don't need to understand what it does. The problem I have is that despite instantiating the ITracingService, any tracing content that I generate using the Trace(...) method is obfuscated at runtime for real-time workflows only. In other words, if I run my workflow asynchronously and (deliberately) throw an Exception, I get to see the trace log in the corresponding system job record. If I simply switch the workflow to be "real-time" (synchronous) then I still get an exception and I still get any custom exception text, but of course there is no corresponding systemjob generated for realtime workflows so, like a plug-in, I am seeking my Trace output in the downloadable log file that is presented when an exception occurs. In this case, my Traces are not visible but I get what appears to be Microsoft's trace log from (perhaps) the parent context that hosts the workflow - you can see that it is referencing the steps in my workflow process definition:
[Microsoft.Crm.ObjectModel: Microsoft.Crm.Extensibility.InternalOperationPlugin]
[46f6cf4c-14ae-4f1e-98a1-eae99a37e95c: ExecuteWorkflow]
Starting sync workflow 'MyTestWorkflow', Id: ca8782b1-7ca4-e311-a055-6c3be5be5f78
Entering CreateStep1_step:
Entering CustomActivityStep2_step:
Sync workflow '__Test' terminated with error 'Unexpected exception from plug-in (Execute): My.Test.WF.DoSomething: System.NullReferenceException: Object reference not set to an instance of an object.'
In my assembly My.Test.WF.DoSomething I access the Tracing Service at invocation and immediately start writing via the Trace() method, e.g.
_trace.Trace("Starting Greg's custom code...");
This is only an example, but the point is, my tracing works when asynchronous but is "lost" when synchronous.
Any ideas?
The process sessions section on the corresponding workflow designer form contains the full exception message.
The problem is that the full exception message does not contains the trace created through the ITracingService Trace method, just contains the exception that's been thrown by the platform, no user traces are included in the comments tab of the process section.
I think the best approach for development purpose is to use a StringBuilder instead of ITracingService and throw the exception using StringBuider.toString() as the message.
As for production release, perhaps the best approach is to use a custom entity to trace the errors in runtime, or not use custom workflows activities on synchronous workflows at all.
Cheers.
Related
When Spring Webflow receives an invalid eventId it throws a NoMatchingTransitionException. This, in turn, throws a 500 error which is detected by vulnerability scanners. CAS 6.X uses a custom webflow to implement it's login functionality. According the the link below under the "Live Happily" heading, the CAS documentation seems to frown upon altering the flow.
https://apereo.github.io/cas/6.1.x/webflow/Webflow-Customization-Extensions.html
I need to be able to handle these errors and throw another status, such as a 400 bad request. In previous versions of CAS, there was a login-webflow.xml file where transitions for invalid eventIds could be defined. I realize this is altering the flow, but seemed fairly safe and intuitive. It seems that this has been moved to a pure Java implementation. Is that correct? If there is a way to simply repeat this process with the new Java implementation, I have been unable to find the resources necessary to do so.
How can I handle these errors gracefully in the new CAS 6?
In previous versions of CAS, there was a login-webflow.xml file where transitions for invalid eventIds could be defined.
Judging by the very same link you shared, the same file appears to be available at: src/main/resources/webflow/login-webflow.xml
If you do not have this file in your build, you will need to pull it in your overlay at that path and address. For the version you shared, the original copy of the file is available at: https://github.com/apereo/cas/blob/6.1.x/webapp/cas-server-webapp-resources/src/main/resources/webflow/login/login-webflow.xml
It seems that this has been moved to a pure Java implementation. Is that correct?
Yes.
If there is a way to simply repeat this process with the new Java implementation, I have been unable to find the resources necessary to do so. How can I handle these errors gracefully in the new CAS 6?
It depends on what you mean by "simply".
If you're familiar with Spring Webflow XML, you can alter the same XML file and have it do what you want. Typically, this involves adding global exception handlers that trigger into a new state that you would define. A simple google search turned this up:
<global-transitions>
<transition on-exception="example.MyBusinessException" to="state3" />
</global-transitions>
Alternatively, the same link you shared shows that a flow can be altered dynamically at runtime and this is the recommended approach since XML config will be removed eventually (and has been):
#Override
protected void doInitialize() throws Exception {
final Flow flow = super.getLoginFlow();
// Magic happens; Call 'super' to see what you have access to and alter the flow.
}
Here, you can effectively do the same as you would in XML; create exception handlers for your particular type of error and have it navigate to a different state. The super class provides utility methods that let you create states, views, transitions, etc.
Something like this:
val h = new TransitionExecutingFlowExecutionExceptionHandler();
h.add(SomeException.class, "stateId");
flow.getExceptionHandlerSet().add(h);
Please see: https://fawnoos.com/2021/08/20/cas64-webflow-extensions/ (Note that the link here applies to CAS 6.4.x)
I have a from with a plugin that updates a record in the DB. I see the updated data in the record in the DB, but when i load the form the updated data does not show.
there are no business rules, the is no JS OnLoad event.
The record is inactive in the DB when the data is updated, but i don' think that should matter
Any ideas as to what I am overlooking?
You're correct that the changes should still save to an inactive record.
Under Advanced Settings > Administration > System Settings > Customization you can set "Enable logging to plug-in trace log" to "All".
Then in the plugin you can use the ITracingService to log messages, which are then visible in Advanced Settings > Plugin-In Trace Log.
You could log the fields' values before and after you set them to confirm that they're getting set.
Or, for a "quick and dirty" option store the fields' values before you set them, then after you set them, throw an InvalidPluginExecution exception containing the "before and after" values. The exception message will pop up right in the UI.
We'd be better able to analyze the issue if you post your code.
On a related note, when writing plugins I often separate the logic out into a Visual Studio Shared Project. I reference that project from a console app and the plugin assembly. The console app enables me to test and debug locally with full VS debugging capabilities before publishing the plugin. Of course there are certain things from the context that can be tricky to mock in the Console app, so your mileage may vary depending on the application.
There are also testing frameworks like FakeXrmEasy, but I have yet to try any of those.
Is there any pattern for cross-platform error handling in MvvmCross, mainly Android and iOS?
For example:
In the model a call is made to a webservice. The call fails e.g. due to network not available.
Imagine a text input field that my application checks. When it contains abc, everything is fine. Otherwise an error message shall be shown.
How to propagate the error messages for these cases to the view? How to process the error message in the view?
Can someone provide some best practice samples?
Microsoft AppCenter Crashes has native and Xamarin modules for iOS and Android which will allow you to report and view handled and unhandled exceptions.
Polly can be used to handle automatic retry of web requests.
MvvmCross has a logging system that can be connected to NLog, Serilog, etc. to log errors/information to a log file on the device. You can attach the log file to AppCenter Error Report (although it is currently limited to 7MB file attachments)
FluentValidation can be used to validate objects. You could handle the validation in the ViewModel then use a MvvmCross Interaction to pass the validation errors from the ViewModel to the View. I use this approach and call TextInputLayout.SetError() in the Android view to show the error message next to the input field.
I need to cancel renderProcessing (doView method) from executing after processing Action or Event phase (As i don't want the whole page or any portlets to be refreshed). Something like ajax resource acquiring which is not leading to refresh all portlets (I mean serveResource method). Can we use "destroy()" method at the end of ProcessAction or ProcessEvent to prevent renderPhase from executing. I'm using MVCPortlet framework and events ipc extensively in my portlets. Thanks for your help.
As Georgy Gobozov stated in the comment: The answer to your question is "No".
If you are using the standard portlet request handling and rely on event handling, you're bound to a full page reload. There's nothing that keeps you from implementing custom event handling (e.g. with JS on the browser, through your business layer etc.) but unfortunately you'll have to do exactly this.
When you start the original request, e.g. through an action handler, the page has already started to reload (from the browser perspective). Any attempt to cancel the processing server side will result in the stream to break and the browser signalling an error on the page (e.g. "can't load": The result must come with an HTTP status - and it will most likely be an error code (e.g. 50x), or it must contain the whole page's HTML.
VB 6.0 does not have any global handler.To catch runtime errors,we need to add a handler in each method where we feel an error can occur.But, still some places might be left out.So,we end up getting runtime errors.Adding error handler in all the methods of an application,the only way?
No there is no way to add a global error handler in VB6. However, you do not need to add an error handler in every method. You only really need to add an error handler in every event handler. E.g. Every click event,load event, etc
While errors do propogate upwards, VB6 has no way to do a stack trace, so you never know which method raised the error. Unfortunately, if you need this information, you have to add a handler to each method just to log where you were.
Also: errors do propagate upwards: if method X calls methods Y and Z, a single error handler in method X will cover all three methods.
I discovered this tool yesterday:
http://www.everythingaccess.com/simplyvba-global-error-handler.htm
It is a commercial product that enables global error handling in VB6 and VBA applications.
It has its cost but does its job perfectly. I have seen other tools (free though) helping in this VB6 mangle, but none can cover a true real global error handling like "SimplyVB6 Global Error Handler for VB6" does.
With "SimplyVB6 Global Error Handler for VB6", there is no need to change any line of existing code, and no need to number the lines of code (via a plug-in or something).
Just enable Global error handling (one line of code in the main module) and you are all set.
"SimplyVB6 Global Error Handler for VB6":
can show the call stack with real module and function names, as well as display the source code line.
Works only with P-Code compiled VB6 programs.
can work via early or late binding (no DLL Hell).
I am not in any way affiliated to www.everythingaccess.com, just happy to have found it yesterday afternoon, was kind of looking at this problem again as one of my customers was having bugs in our VB6 application. I was able to test the tool yesterday afternoon, exchanging emails with the www.everythingaccess.com support and getting the evaluation product per mail.
Their web side does not allow yet to download the evaluation version of the VB6 product, you have to email them but they are answering in less than an hour.
on error resume next - is kinda close but its been a while.
you might want to look up any caveats