These failures often occur when AJAX requests are being fired against the Engine. In most cases an Html Dialog has already been closed in the Process (Dialog Exit Event), but the users still sees the last view (and eventually Ajax Requests are being provoked) just before the redirect to the next real page within the workflow app is being sent. To find the ajax element on the view which causes the problem is not that easy. As there are probably many elements with AJAX capabilities within your User Dialog. But you can get close to the element by enabling request logs on the Engine. Request logs will expose all data that is sent from a Dialog User and save it for later analysis. For ajax requests this is interesting because the payload of such a request will contain the AJAX ids that are being asked to update. And with this information you should be able to detect the element on the view that fires these requests. Client request: ![alt text][1] Server side log of this request: ![alt text][2] ---------- **How to enable Request Logs** **WARNING**: enabled request logs will produce tremendous log data. Check that enough disk space is available or the engine will even refuse to start once there is no space left. [1.] Enable the internal tomcat request log filter in `webapps/ivy/WEB-INF/web.xml` by adding the following xml config: <filter> <filter-name>requestdumper</filter-name> <filter-class>org.apache.catalina.filters.RequestDumperFilter</filter-class> </filter> <filter-mapping> <filter-name>requestdumper</filter-name> <url-pattern>/faces/instances/*</url-pattern> <dispatcher>REQUEST</dispatcher> </filter-mapping> ![alt text][3] [2.] Route tomcat logs into an extra request log file by configuring `configuration/log4jconfig.xml` with the `configuration/log4jconfig.xml`. Do so by adding the following xml config: <log4j:configuration debug="false" xmlns:log4j="http://jakarta.apache.org/log4j/"> .... <!-- Defines a log file called request.log --> <appender name="requestLog" class="org.apache.log4j.DailyRollingFileAppender"> <param name="File" value="${user.dir}/logs/request.log"/> <param name="DatePattern" value="'.'yyyy-MM-dd"/> <layout class="org.apache.log4j.IvyLog4jLayout"> <param name="DateFormat" value="HH:mm:ss"/> </layout> </appender> <!-- limit the pressure on the filesystem --> <appender name="asyncRequestLog" class="org.apache.log4j.AsyncAppender"> <param name="BufferSize" value="50000" /> <appender-ref ref="requestLog" /> </appender> <!-- route RequestDumperFilter logs to own file --> <category name="org.apache.catalina.filters.RequestDumperFilter" class="ch.ivyteam.log.Logger"> <appender-ref ref="asyncRequestLog"/> <priority value="DEBUG"/> </category> .... </log4j:configuration> ![alt text][4] [1]: https://answers.axonivy.com/upfiles/firefox_xhrParams.png [2]: https://answers.axonivy.com/upfiles/tomcatRequestLog_xhrParams.png [3]: https://answers.axonivy.com/upfiles/webXml_withREquestFilter.png [4]: https://answers.axonivy.com/upfiles/log4jconfig_withAsyncRequestLogging.png

These failures often occur when AJAX requests are being fired against the Engine. In most cases an Html Dialog has already been closed in the Process (Dialog Exit Event), but the users still sees the last view (and eventually Ajax Requests are being provoked) just before the redirect to the next real page within the workflow app is being sent. To find the ajax element on the view which causes the problem is not that easy. As there are probably many elements with AJAX capabilities within your User Dialog. But you can get close to the element by enabling request logs on the Engine. Request logs will expose all data that is sent from a Dialog User and save it for later analysis. For ajax requests this is interesting because the payload of such a request will contain the AJAX ids that are being asked to update. And with this information you should be able to detect the element on the view that fires these requests. Client request: ![alt text][1] Server side log of this request: ![alt text][2] ---------- **How to enable Request Logs** <div style="background-color:yellow">Be warned that **WARNING**: enabled request logs will produce tremendous log data. Check that enough disk space is available or the engine will even refuse to start once there is no space left.</div>left. [1.] Enable the internal tomcat request log filter in `webapps/ivy/WEB-INF/web.xml` by adding the following xml config: <filter> <filter-name>requestdumper</filter-name> <filter-class>org.apache.catalina.filters.RequestDumperFilter</filter-class> </filter> <filter-mapping> <filter-name>requestdumper</filter-name> <url-pattern>/faces/instances/*</url-pattern> <dispatcher>REQUEST</dispatcher> </filter-mapping> ![alt text][3] [2.] Route tomcat logs into an extra request log file by configuring `configuration/log4jconfig.xml` by adding the following xml config: <log4j:configuration debug="false" xmlns:log4j="http://jakarta.apache.org/log4j/"> .... <!-- Defines a log file called request.log --> <appender name="requestLog" class="org.apache.log4j.DailyRollingFileAppender"> <param name="File" value="${user.dir}/logs/request.log"/> <param name="DatePattern" value="'.'yyyy-MM-dd"/> <layout class="org.apache.log4j.IvyLog4jLayout"> <param name="DateFormat" value="HH:mm:ss"/> </layout> </appender> <!-- limit the pressure on the filesystem --> <appender name="asyncRequestLog" class="org.apache.log4j.AsyncAppender"> <param name="BufferSize" value="50000" /> <appender-ref ref="requestLog" /> </appender> <!-- route RequestDumperFilter logs to own file --> <category name="org.apache.catalina.filters.RequestDumperFilter" class="ch.ivyteam.log.Logger"> <appender-ref ref="asyncRequestLog"/> <priority value="DEBUG"/> </category> .... </log4j:configuration> ![alt text][4] [1]: https://answers.axonivy.com/upfiles/firefox_xhrParams.png [2]: https://answers.axonivy.com/upfiles/tomcatRequestLog_xhrParams.png [3]: https://answers.axonivy.com/upfiles/webXml_withREquestFilter.png [4]: https://answers.axonivy.com/upfiles/log4jconfig_withAsyncRequestLogging.png

These failures often occur when AJAX requests are being fired against the Engine. In most cases an Html Dialog has already been closed in the Process (Dialog Exit Event), but the users still sees the last view (and eventually Ajax Requests are being provoked) just before the redirect to the next real page within the workflow app is being sent. To find the ajax element on the view which causes the problem is not that easy. As there are probably many elements with AJAX capabilities within your User Dialog. But you can get close to the element by enabling request logs on the Engine. Request logs will expose all data that is sent from a Dialog User and save it for later analysis. For ajax requests this is interesting because the payload of such a request will contain the AJAX ids that are being asked to update. And with this information you should be able to detect the element on the view that fires these requests. Client request: ![alt text][1] Server side log of this request: ![alt text][2] ---------- **How to enable Request Logs** <div style="background-color:yellow">Be warned that enabled request logs will produce tremendous log data. Check that enough disk space is available or the engine will even refuse to start once there is no space left.</div> [1.] Enable the internal tomcat request log filter in `webapps/ivy/WEB-INF/web.xml` by adding the following xml config: <filter> <filter-name>requestdumper</filter-name> <filter-class>org.apache.catalina.filters.RequestDumperFilter</filter-class> </filter> <filter-mapping> <filter-name>requestdumper</filter-name> <url-pattern>/faces/instances/*</url-pattern> <dispatcher>REQUEST</dispatcher> </filter-mapping> ![alt text][3] [2.] Route tomcat logs into an extra request log file by configuring `configuration/log4jconfig.xml` by adding the following xml config: <log4j:configuration debug="false" xmlns:log4j="http://jakarta.apache.org/log4j/"> .... <!-- Defines a log file called request.log --> <appender name="requestLog" class="org.apache.log4j.DailyRollingFileAppender"> <param name="File" value="${user.dir}/logs/request.log"/> <param name="DatePattern" value="'.'yyyy-MM-dd"/> <layout class="org.apache.log4j.IvyLog4jLayout"> <param name="DateFormat" value="HH:mm:ss"/> </layout> </appender> <!-- limit the pressure on the filesystem --> <appender name="asyncRequestLog" class="org.apache.log4j.AsyncAppender"> <param name="BufferSize" value="50000" /> <appender-ref ref="requestLog" /> </appender> <!-- route RequestDumperFilter logs to own file --> <category name="org.apache.catalina.filters.RequestDumperFilter" class="ch.ivyteam.log.Logger"> <appender-ref ref="asyncRequestLog"/> <priority value="DEBUG"/> </category> .... </log4j:configuration> ![alt text][4] [1]: https://answers.axonivy.com/upfiles/firefox_xhrParams.png [2]: https://answers.axonivy.com/upfiles/tomcatRequestLog_xhrParams.png [3]: https://answers.axonivy.com/upfiles/webXml_withREquestFilter.png [4]: https://answers.axonivy.com/upfiles/log4jconfig_withAsyncRequestLogging.png

These failures often occur when AJAX requests are being fired against the Engine. In most cases an Html Dialog has already been closed in the Process (Dialog Exit Event), but the users still sees the last view (and eventually Ajax Requests are being provoked) just before the redirect to the next real page within the workflow app is being sent. To find the ajax element on the view which causes the problem is not that easy. As there are probably many elements with AJAX capabilities within your User Dialog. But you can get close to the element by enabling request logs on the Engine. Request logs will expose all data that is sent from a Dialog User and save it for later analysis. For ajax requests this is interesting because the payload of such a request will contain the AJAX ids that are being asked to update. And with this information you should be able to detect the element on the view that fires these requests. Client request: ![alt text][1] Server side log of this request: ![alt text][2] ---------- **How to enable Request Logs** [1.] Enable the internal tomcat request log filter in `webapps/ivy/WEB-INF/web.xml` by adding the following xml config: <filter> <filter-name>requestdumper</filter-name> <filter-class>org.apache.catalina.filters.RequestDumperFilter</filter-class> </filter> <filter-mapping> <filter-name>requestdumper</filter-name> <url-pattern>/faces/instances/*</url-pattern> <dispatcher>REQUEST</dispatcher> </filter-mapping> </web-app> ![alt text][3] 2. [2.] Route tomcat logs into an extra request log file by configuring `configuration/log4jconfig.xml` by adding the following xml config: <log4j:configuration debug="false" xmlns:log4j="http://jakarta.apache.org/log4j/"> .... <!-- Defines a log file called request.log --> <appender name="requestLog" class="org.apache.log4j.DailyRollingFileAppender"> <param name="File" value="${user.dir}/logs/request.log"/> <param name="DatePattern" value="'.'yyyy-MM-dd"/> <layout class="org.apache.log4j.IvyLog4jLayout"> <param name="DateFormat" value="HH:mm:ss"/> </layout> </appender> <!-- limit the pressure on the filesystem --> <appender name="asyncRequestLog" class="org.apache.log4j.AsyncAppender"> <param name="BufferSize" value="50000" /> <appender-ref ref="requestLog" /> </appender> <!-- route RequestDumperFilter logs to own file --> <category name="org.apache.catalina.filters.RequestDumperFilter" class="ch.ivyteam.log.Logger"> <appender-ref ref="asyncRequestLog"/> <priority value="DEBUG"/> </category> .... </log4j:configuration> ![alt text][4] [1]: https://answers.axonivy.com/upfiles/firefox_xhrParams.png [2]: https://answers.axonivy.com/upfiles/tomcatRequestLog_xhrParams.png [3]: https://answers.axonivy.com/upfiles/webXml_withREquestFilter.png [4]: https://answers.axonivy.com/upfiles/log4jconfig_withAsyncRequestLogging.png

These failures often occur when AJAX requests are being fired against the Engine. In most cases an Html Dialog has already been closed in the Process (Dialog Exit Event), but the users still sees the last view (and eventually Ajax Requests are being provoked) just before the redirect to the next real page within the workflow app is being sent. To find the ajax element on the view which causes the problem is not that easy. As there are probably many elements with AJAX capabilities within your User Dialog. But you can get close to the element by enabling request logs on the Engine. Request logs will expose all data that is sent from a Dialog User and save it for later analysis. For ajax requests this is interesting because the payload of such a request will contain the AJAX ids that are being asked to update. And with this information you should be able to detect the element on the view that fires these requests. Client request: ![alt text][1] Server side log of this request: ![alt text][2] ---------- **How to enable Request Logs** [1.] Enable the internal tomcat request log filter in `webapps/ivy/WEB-INF/web.xml` by adding the following xml config: <filter> <filter-name>requestdumper</filter-name> <filter-class>org.apache.catalina.filters.RequestDumperFilter</filter-class> </filter> <filter-mapping> <filter-name>requestdumper</filter-name> <url-pattern>/faces/instances/*</url-pattern> <dispatcher>REQUEST</dispatcher> </filter-mapping> </web-app> ![alt text][3] 2. Route tomcat logs into an extra request log file by configuring `configuration/log4jconfig.xml` by adding the following xml config: <log4j:configuration debug="false" xmlns:log4j="http://jakarta.apache.org/log4j/"> .... <!-- Defines a log file called request.log --> <appender name="requestLog" class="org.apache.log4j.DailyRollingFileAppender"> <param name="File" value="${user.dir}/logs/request.log"/> <param name="DatePattern" value="'.'yyyy-MM-dd"/> <layout class="org.apache.log4j.IvyLog4jLayout"> <param name="DateFormat" value="HH:mm:ss"/> </layout> </appender> <!-- limit the pressure on the filesystem --> <appender name="asyncRequestLog" class="org.apache.log4j.AsyncAppender"> <param name="BufferSize" value="50000" /> <appender-ref ref="requestLog" /> </appender> <!-- route RequestDumperFilter logs to own file --> <category name="org.apache.catalina.filters.RequestDumperFilter" class="ch.ivyteam.log.Logger"> <appender-ref ref="asyncRequestLog"/> <priority value="DEBUG"/> </category> .... </log4j:configuration> ![alt text][4] [1]: https://answers.axonivy.com/upfiles/firefox_xhrParams.png [2]: https://answers.axonivy.com/upfiles/tomcatRequestLog_xhrParams.png [3]: https://answers.axonivy.com/upfiles/webXml_withREquestFilter.png [4]: https://answers.axonivy.com/upfiles/log4jconfig_withAsyncRequestLogging.png

These failures often occur when AJAX requests are being fired against the Engine. In most cases an Html Dialog has already been closed in the Process (Dialog Exit Event), but the users still sees the last view (and eventually Ajax Requests are being provoked) just before the redirect to the next real page within the workflow app is being sent. To find the ajax element on the view which causes the problem is not that easy. As there are probably many elements with AJAX capabilities within your User Dialog. But you can get close to the element by enabling request logs on the Engine. Request logs will expose all data that is sent from a Dialog User and save it for later analysis. For ajax requests this is interesting because the payload of such a request will contain the AJAX ids that are being asked to update. And with this information you should be able to detect the element on the view that fires these requests. Client request: ![alt text][1] Server side log of this request: ![alt text][2] ---------- **How to enable Request Logs** 1. [1.] Enable the internal tomcat request log filter in `webapps/ivy/WEB-INF/web.xml` by adding the following xml config: <filter> <filter-name>requestdumper</filter-name> <filter-class>org.apache.catalina.filters.RequestDumperFilter</filter-class> </filter> <filter-mapping> <filter-name>requestdumper</filter-name> <url-pattern>/faces/instances/*</url-pattern> <dispatcher>REQUEST</dispatcher> </filter-mapping> </web-app> ![alt text][3] 2. Route tomcat logs into an extra request log file by configuring `configuration/log4jconfig.xml` by adding the following xml config: <log4j:configuration debug="false" xmlns:log4j="http://jakarta.apache.org/log4j/"> .... <!-- Defines a log file called request.log --> <appender name="requestLog" class="org.apache.log4j.DailyRollingFileAppender"> <param name="File" value="${user.dir}/logs/request.log"/> <param name="DatePattern" value="'.'yyyy-MM-dd"/> <layout class="org.apache.log4j.IvyLog4jLayout"> <param name="DateFormat" value="HH:mm:ss"/> </layout> </appender> <!-- limit the pressure on the filesystem --> <appender name="asyncRequestLog" class="org.apache.log4j.AsyncAppender"> <param name="BufferSize" value="50000" /> <appender-ref ref="requestLog" /> </appender> <!-- route RequestDumperFilter logs to own file --> <category name="org.apache.catalina.filters.RequestDumperFilter" class="ch.ivyteam.log.Logger"> <appender-ref ref="asyncRequestLog"/> <priority value="DEBUG"/> </category> .... </log4j:configuration> ![alt text][4] [1]: https://answers.axonivy.com/upfiles/firefox_xhrParams.png [2]: https://answers.axonivy.com/upfiles/tomcatRequestLog_xhrParams.png [3]: https://answers.axonivy.com/upfiles/webXml_withREquestFilter.png [4]: https://answers.axonivy.com/upfiles/log4jconfig_withAsyncRequestLogging.png

These failures often occur when AJAX requests are being fired against the Engine. In most cases an Html Dialog has already been closed in the Process (Dialog Exit Event), but the users still sees the last view (and eventually Ajax Requests are being provoked) just before the redirect to the next real page within the workflow app is being sent. To find the ajax element on the view which causes the problem is not that easy. As there are probably many elements with AJAX capabilities within your User Dialog. But you can get close to the element by enabling request logs on the Engine. Request logs will expose all data that is sent from a Dialog User and save it for later analysis. For ajax requests this is interesting because the payload of such a request will contain the AJAX ids that are being asked to update. And with this information you should be able to detect the element on the view that fires these requests. Client request: ![alt text][1] Server side log of this request: ![alt text][2] ---------- **How to enable Request Logs** 1. Enable the internal tomcat request log filter in `webapps/ivy/WEB-INF/web.xml` by adding the following xml config: <web-app> <filter> <filter-name>requestdumper</filter-name> <filter-class> org.apache.catalina.filters.RequestDumperFilter </filter-class> <filter-class>org.apache.catalina.filters.RequestDumperFilter</filter-class> </filter> <filter-mapping> <filter-name>requestdumper</filter-name> <url-pattern>/faces/instances/*</url-pattern> <dispatcher>REQUEST</dispatcher> </filter-mapping> </web-app> ![alt text][3] 2. Route tomcat logs into an extra request log file by configuring `configuration/log4jconfig.xml` by adding the following xml config: <log4j:configuration debug="false" xmlns:log4j="http://jakarta.apache.org/log4j/"> .... <!-- Defines a log file called request.log --> <appender name="requestLog" class="org.apache.log4j.DailyRollingFileAppender"> <param name="File" value="${user.dir}/logs/request.log"/> <param name="DatePattern" value="'.'yyyy-MM-dd"/> <layout class="org.apache.log4j.IvyLog4jLayout"> <param name="DateFormat" value="HH:mm:ss"/> </layout> </appender> <!-- limit the pressure on the filesystem --> <appender name="asyncRequestLog" class="org.apache.log4j.AsyncAppender"> <param name="BufferSize" value="50000" /> <appender-ref ref="requestLog" /> </appender> <!-- route RequestDumperFilter logs to own file --> <category name="org.apache.catalina.filters.RequestDumperFilter" class="ch.ivyteam.log.Logger"> <appender-ref ref="asyncRequestLog"/> <priority value="DEBUG"/> </category> .... </log4j:configuration> ![alt text][4] [1]: https://answers.axonivy.com/upfiles/firefox_xhrParams.png [2]: https://answers.axonivy.com/upfiles/tomcatRequestLog_xhrParams.png [3]: https://answers.axonivy.com/upfiles/webXml_withREquestFilter.png [4]: https://answers.axonivy.com/upfiles/log4jconfig_withAsyncRequestLogging.png

These failures often occur when AJAX requests are being fired against the Engine. In most cases an Html Dialog has already been closed in the Process (Dialog Exit Event), but the users still sees the last view (and eventually Ajax Requests are being provoked) just before the redirect to the next real page within the workflow app is being sent. To find the ajax element on the view which causes the problem is not that easy. As there are probably many elements with AJAX capabilities within your User Dialog. But you can get close to the element by enabling request logs on the Engine. Request logs will expose all data that is sent from a Dialog User and save it for later analysis. For ajax requests this is interesting because the payload of such a request will contain the AJAX ids that are being asked to update. And with this information you should be able to detect the element on the view that fires these requests. Client request: ![alt text][1] Server side log of this request: ![alt text][2] ---------- **How to enable Request Logs** 1. Enable the internal tomcat request log filter in `webapps/ivy/WEB-INF/web.xml` by adding the following xml config: <web-app> ... <filter> <filter-name>requestdumper</filter-name> <filter-class> org.apache.catalina.filters.RequestDumperFilter </filter-class> </filter> <filter-mapping> <filter-name>requestdumper</filter-name> <url-pattern>/faces/instances/*</url-pattern> <dispatcher>REQUEST</dispatcher> </filter-mapping> </web-app> ![alt text][3] 2. Route tomcat logs into an extra request log file by configuring `configuration/log4jconfig.xml` by adding the following xml config: <log4j:configuration debug="false" xmlns:log4j="http://jakarta.apache.org/log4j/"> .... <!-- Defines a log file called request.log --> <appender name="requestLog" class="org.apache.log4j.DailyRollingFileAppender"> <param name="File" value="${user.dir}/logs/request.log"/> <param name="DatePattern" value="'.'yyyy-MM-dd"/> <layout class="org.apache.log4j.IvyLog4jLayout"> <param name="DateFormat" value="HH:mm:ss"/> </layout> </appender> <!-- limit the pressure on the filesystem --> <appender name="asyncRequestLog" class="org.apache.log4j.AsyncAppender"> <param name="BufferSize" value="50000" /> <appender-ref ref="requestLog" /> </appender> <!-- route RequestDumperFilter logs to own file --> <category name="org.apache.catalina.filters.RequestDumperFilter" class="ch.ivyteam.log.Logger"> <appender-ref ref="asyncRequestLog"/> <priority value="DEBUG"/> </category> .... </log4j:configuration> ![alt text][4] [1]: https://answers.axonivy.com/upfiles/firefox_xhrParams.png [2]: https://answers.axonivy.com/upfiles/tomcatRequestLog_xhrParams.png [3]: https://answers.axonivy.com/upfiles/webXml_withREquestFilter.png [4]: https://answers.axonivy.com/upfiles/log4jconfig_withAsyncRequestLogging.png

These failures often occur when AJAX requests are being fired against the Engine. In most cases an Html Dialog has already been closed in the Process (Dialog Exit Event), but the users still sees the last view (and eventually Ajax Requests are being provoked) just before the redirect to the next real page within the workflow app is being sent. To find the ajax element on the view which causes the problem is not that easy. As there are probably many elements with AJAX capabilities within your User Dialog. But you can get close to the element by enabling request logs on the Engine. Request logs will expose all data that is sent from a Dialog User and save it for later analysis. For ajax requests this is interesting because the payload of such a request will contain the AJAX ids that are being asked to update. And with this information you should be able to detect the element on the view that fires these requests. Client request: ![alt text][1] Server side log of this request: ![alt text][2] ---------- **How to enable Request Logs** - 1. Enable the internal tomcat request log filter in `webapps/ivy/WEB-INF/web.xml` by adding the following xml config: <web-app> ... <filter> <filter-name>requestdumper</filter-name> <filter-class> org.apache.catalina.filters.RequestDumperFilter </filter-class> </filter> <filter-mapping> <filter-name>requestdumper</filter-name> <url-pattern>/faces/instances/*</url-pattern> <dispatcher>REQUEST</dispatcher> </filter-mapping> </web-app> ![alt text][3] - 2. Route tomcat logs into an extra request log file by configuring `configuration/log4jconfig.xml` by adding the following xml config: <log4j:configuration debug="false" xmlns:log4j="http://jakarta.apache.org/log4j/"> .... <!-- Defines a log file called request.log --> <appender name="requestLog" class="org.apache.log4j.DailyRollingFileAppender"> <param name="File" value="${user.dir}/logs/request.log"/> <param name="DatePattern" value="'.'yyyy-MM-dd"/> <layout class="org.apache.log4j.IvyLog4jLayout"> <param name="DateFormat" value="HH:mm:ss"/> </layout> </appender> <!-- limit the pressure on the filesystem --> <appender name="asyncRequestLog" class="org.apache.log4j.AsyncAppender"> <param name="BufferSize" value="50000" /> <appender-ref ref="requestLog" /> </appender> <!-- route RequestDumperFilter logs to own file --> <category name="org.apache.catalina.filters.RequestDumperFilter" class="ch.ivyteam.log.Logger"> <appender-ref ref="asyncRequestLog"/> <priority value="DEBUG"/> </category> .... </log4j:configuration> ![alt text][4] [1]: https://answers.axonivy.com/upfiles/firefox_xhrParams.png [2]: https://answers.axonivy.com/upfiles/tomcatRequestLog_xhrParams.png [3]: https://answers.axonivy.com/upfiles/webXml_withREquestFilter.png [4]: https://answers.axonivy.com/upfiles/log4jconfig_withAsyncRequestLogging.png

These failures often occur when AJAX requests are being fired against the Engine. In most cases an Html Dialog has already been closed in the Process (Dialog Exit Event), but the users still sees the last view (and eventually Ajax Requests are being provoked) just before the redirect to the next real page within the workflow app is being sent. To find the ajax element on the view which causes the problem is not that easy. As there are probably many elements with AJAX capabilities within your User Dialog. But you can get close to the element by enabling request logs on the Engine. Request logs will expose all data that is sent from a Dialog User and save it for later analysis. For ajax requests this is interesting because the payload of such a request will contain the AJAX ids that are being asked to update. And with this information you should be able to detect the element on the view that fires these requests. Client request: ![alt text][1] Server side log of this request: ![alt text][2] ---------- **How to enable Request Logs** ... - Enable the internal tomcat request log filter in `webapps/ivy/WEB-INF/web.xml` ![alt text][3] - Route tomcat logs into an extra request log file by configuring `configuration/log4jconfig.xml` ![alt text][4] [1]: http://https://answers.axonivy.com/upfiles/firefox_xhrParams.png [2]: https://answers.axonivy.com/upfiles/tomcatRequestLog_xhrParams.png [3]: https://answers.axonivy.com/upfiles/webXml_withREquestFilter.png [4]: https://answers.axonivy.com/upfiles/log4jconfig_withAsyncRequestLogging.png

This These failures often occur when AJAX requests are being fired against the Engine. In most cases an Html Dialog has already been closed in the Process (Dialog Exit Event), but the users still sees the last view (and eventually Ajax Requests are being provoked) just before the redirect to the next real page within the workflow app is being sent. To find the ajax element on the view which causes the problem is difficult. not that easy. As there are probably many elements with AJAX capabilities within your User Dialog. But you can get close to the element by enabling request logs on the Engine. Request logs will expose all data that is sent from a Dialog User and save it for later analysis. For ajax requests this is interesting because the payload of such a request will contain the AJAX ids that are being asked to update. And with this information you should be able to detect the element on the view that fires these requests. **How to enable Request Logs** ... [1]: http://

This failures often occur when AJAX requests are being fired against the Engine. In most cases an Html Dialog has already been closed in the Process (Dialog Exit Event), but the users still sees the last view (and eventually Ajax Requests are being provoked) just before the redirect to the next real page within the workflow app is being sent. To find the ajax element on the view which causes the problem is difficult. As there are probably many elements with AJAX capabilities within your User Dialog. But you can get close to the element by enabling request logs on the Engine. Request logs will expose all data that is sent from a Dialog User and save it for later analysis. For ajax requests this is interesting because the payload of such a request will contain the AJAX ids that are being asked to update. And with this information you should be able to detect the element on the view that fires these requests. **How to enable Request Logs** ... [1]: http://