Best Practices for Choosing a Different Entry Point

Because entry point determination is crucial to the determination of a transaction (i.e., the flow from an ‘OverOps entry point’ to the error location of an event), there are several ways to force the selection of an alternate entry point:

1. By blacklisting packages/classes - If there are packages/classes that could be considered common (across all applications) e.g., Servlet filters, Authentication or Authorization filters, etc., these could be blacklisted. While this helps remove them from entry point consideration, any errors/exceptions thrown by the blacklisted classes will not be captured by OverOps, which is not ideal.
2. By using the Entry Point Customization feature, which allows you to prioritize or de-prioritize entry points based on business logic. This helps achieve the same effect while still capturing events from classes/packages that have been deprioritized.

**Here's how it works:
The stack trace shows an arrow that determines the entry point.

When you review the stack from bottom to top, you may encounter a common filter, such as an authentication, login, or security filter. Because the entry points automatically detected by the system aren't always the most relevant entry point, you need to be able to mark certain packages and classes as a lower priority (for example, common entry points that group events such as logins, common security filters, authentications, etc.).

This is done by adding the common filters to the Deprioritized list. Adding a common class or filter to the list - instead of simply blacklisting it and thereby losing any relevant information it can provide (such as any exception is throws) - means the common entry point is simply moved to the bottom of the priority list while still retaining its data. This means that their information is still stored and they'll still be identified as entry points - as long as there are no other options in the call stack. Therefore, the Reliability Dashboard will show results based on the prioritized entry points, while the exceptions thrown by the common entry points are still retained.

When used in conjunction with the app tiers, can now use the app tier itself as the entry point - by adding it to the Prioritized list. So that now that app tier will be recognized as the entry point,giving us a much better transaction.

To understand how the entry point customization works, lets look at a typical call stack:

Now, let's copy the call stack:

Logged Error: Unable to create customer using customerNumber: CUST5857
    at org.apache.log4j.Category.forcedLog(String, Priority, Object, Throwable)
    at org.apache.log4j.Category.log(String, Priority, Object, Throwable)
    at org.slf4j.impl.Log4jLoggerAdapter.error(String, Object, Object)
    at com.shoppingcart1.dao.impl.CustomerDAOImpl.create(String)
    at com.shoppingcart1.manager.CustomerManager.create(String)
    at com.empire.billing.shoppingcart.workflow.ShoppingCartWF.workflow11()
    at com.empire.billing.workflow.tasks.ShoppingCartTask.executeMultipleWorkflows()
    at com.empire.billing.workflow.tasks.ShoppingCartTask.run()
    at com.empire.common.App1EntryPoint2.doPost(HttpServletRequest, HttpServletResponse)
    at com.empire.common.App1EntryPoint2.doGet(HttpServletRequest, HttpServletResponse)
    at javax.servlet.http.HttpServlet.service(HttpServletRequest, HttpServletResponse)
    at javax.servlet.http.HttpServlet.service(ServletRequest, ServletResponse)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ServletRequest, ServletResponse)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ServletRequest, ServletResponse)
    at org.apache.tomcat.websocket.server.WsFilter.doFilter(ServletRequest, ServletResponse, FilterChain)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ServletRequest, ServletResponse)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ServletRequest, ServletResponse)
    at org.apache.catalina.core.StandardWrapperValve.invoke(Request, Response)
    at org.apache.catalina.core.StandardContextValve.invoke(Request, Response)
    at org.apache.catalina.authenticator.AuthenticatorBase.invoke(Request, Response)
    at org.apache.catalina.core.StandardHostValve.invoke(Request, Response)
    at org.apache.catalina.valves.ErrorReportValve.invoke(Request, Response)
    at org.apache.catalina.valves.AbstractAccessLogValve.invoke(Request, Response)
    at org.apache.catalina.core.StandardEngineValve.invoke(Request, Response)
    at org.apache.catalina.connector.CoyoteAdapter.service(Request, Response)
    at org.apache.coyote.http11.Http11Processor.service(SocketWrapperBase)
    at org.apache.coyote.AbstractProcessorLight.process(SocketWrapperBase, SocketEvent)
    at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(SocketWrapperBase, SocketEvent)
    at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun()
    at org.apache.tomcat.util.net.SocketProcessorBase.run()
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor$Worker)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run()
    at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run()
    at java.lang.Thread.run()

As you can see, the entry point is currently set to the common entry point empire.common.
However the actual entry point should be empire.billing, which is the first event that's not common.

By setting empire.billing as the prioritized entry point, and marking empire.common as a deprioritized entry point, the common entry point information is retained, but now you're looking at the event from the actual relevant point.

📘

Note

Changing the entry point after an event is created will not affect it in the UI. When you add an entry point, the change will be reflected only for new combinations of the EntryPoint, EventLocation and ErrorType.