I have uncovered what I believe to be a bug in the REST implementation for Orchestration Designer. It's an odd situation, not one that is common, I feel pretty sure about that. in a special situation, if the REST response contains a non-200 HTTP code, an exception is thrown that cannot be handled by the Orchestration Designer application and the call dies abruptly.

The special situation is when there is no showcaughtexceptions key in the data/ddrt.properties file. In this situation, the Orchestration Designer application will throw a NullPointerException, wrapped in a ServletException, wrapped in a RuntimeException. This exception is handled outside the Orchestration Designer application so the Orchestration Designer application has no opportunity to handle the error. As a result, the call simply dies. See the attached 401-Exception.txt file that shows the exception in the trace.

When the showcaughtexceptions key exists in the data/ddrt.properties file, the non-200 response can be appropriately handled by the Orchestration Designer application. See the 401-Success.txt file that shows the complete trace.

The same application was used for both of these tests, with the only difference between the 2 is the exclusion/inclusion of the showcaughtexceptions key in the data/ddrt.properties file. The REST web service operation in question is wrapped in a try/catch in both situations. Only the situation which includes the showcaughtexceptions key in the data/ddrt.properties file is handled correctly within the application.

I can provide a simple REST web service that returns a 401 unauthorized code and a sample application is necessary. It will take a couple of hours to setup, but I can have it to you tomorrow. Let me know either way.

Michael

Maybe it is because it is Monday, but I am not seeing what you are talking about it the 2 traces. Both traces reach the next node after the web service call "ParseTwilioJson1".

Sorry Ross. It's been a busy week. I've attached a lot of the exception that's thrown when the entry is missing. Not sure why it wasn't in the other log. In the original logs I sent over, you can see the web service request goes out, then the AvayaDisconnect node is executed. The exception in this log is what happens at that point.

Let me know if you need anything else. :)
Thanks,
Michael

Based on the trace you are executing an assignment operation in verifyOtp when the problem seems to arise. But the key info is

"21/07/2017 01:49:16:279 ERROR - 4AD526517AD93AB283E45B9DAE48BD97:/TwilioAUTHYDEmo : EXCEPTION: Transport error: 401 Error: Unauthorized
Fatal Error : caught exception [java.lang.NullPointerException] while trying to report applicaiton exception [javax.servlet.ServletException: EXCEPTION>
"

Which means things are more messed up than it appears. I will play around with this tomorrow.

Sounds good. If it helps, the only change is the inclusion/exclusion of the ddrt.properties showcaughtexceptions key. If the key is there, everything works beautifully. If the key is not there, things break down pretty fast. Let me know if you want a sample app and a rest service that returns the dreaded 401 unauthorized response. This isn't urgent for our development. I'll ensure the key exists in the properties file and there's no issues. Hopefully, if someone else runs into this rare issue, they'll find this thread. :)

Thanks again Ross.
Michael

This is definitely not a REST web service problem. I created a simple test case where a jsp page reutrns a 401 and it worked exactly the same way whether or not I have show caught exceptions enabled. There is some other issue a play here.

It's not whether or not the key is enabled, it's whether or not the key exists. Delete the key from the ddrt.properties file, run your example, and let me know if it works the same. That is the only change in my test, the key exists in the properties file for the successful test, the key was deleted from the properties file for the unsuccessful test.

I removed

showcaughtexceptions=disabled

from the ddrt.properties file and still same result, worked as expected.

Hmmm, then something else is going on somewhere. This same test was conducted on 2 separate installations of Orchestration Designer 7.1.0.12, on 2 separate computers, in 2 separate countries. One in the U.S. and one in India. Both results were identical. The only difference between the successful and unsuccessful test is removing the key from the ddrt.properties file. This also seems to coincide with the error message:

Fatal Error : caught exception [java.lang.NullPointerException] while trying to report applicaiton exception [javax.servlet.ServletException: EXCEPTION>

To me, this says that because the key doesn't exist, the framework can't determine whether or not to report the exception (properties.getProperty(String) can return null if the key doesn't exist). Our logs show this as well. In the fail log, after the web request is sent, the result comes back as a 401 (as demonstrated by SOAP UI interception), and the application terminates (AvayaDisconnectHandler). In the success log, the web service is sent, the result comes back as 401, and the application re-prompts the caller as the programming directs. Again, since the only difference between the successful and unsuccessful tests is the removal of the key from the properties file, this seemed like a logical deduction.

Since adding the key to the ddrt.properties file is our solution, consider this thread is resolved. Thank you for your time. :)

ok I used REST and not SOAP.

We used REST also, not SOAP. My mistake with referencing SOAP UI, I'm debugging multiple issues on multiple machines with multiple systems. For this issue, we use Burp Suite to capture the stream.

I am Dongbo from Avaya BBE team.
I found the following java code of evaluate() function of CaptureException class in scert-07.10.12.02.jar would cause this java.lang.NullPointerException.

String value = mySession.getParameter("showcaughtexceptions");
// because without the configuration showcaughtexceptions, the string value is Null.
if (value.equals("enabled") == true) { showEx = true; }
//Null is not string so that Null.equals("enabled") ends up NullPointerException, and DD application would crash with this Exception.

Thanks

zhao dong bo

Yes we know this was fixed on 7/6/16.

Hi Ross

Can I know what released OD version included the fix?
I checked the OD 7.2 release note which was published on August 3, 2017 just after the fix date 7/6/16 you mentioned,
i can not find any related fix included in the OD version looks match this issue.

Thanks in advance.

Dong Bo, zhao

just put "showcaughtexceptions" in the ddrt.properties
i am not sure what release the change is in.