With the requirement to deliver new software releases faster, and more frequently, many companies choose to automate some, or all, of the code development. Developers can create flows in an integrated development environment (IDE) such as JDeveloper, Eclipse or another tool without seeing a single line of code. Once the process is defined in the flow view the IDE creates one or more files which is read in by the Java Virtual Machine (JVM) or Common Language Runtime (CLR). Once the JVM/CLR has read in the file(s) it will generate the code necessary to execute the flow.

When a performance problem or error occurs within the generated code it can be very complex and time consuming to find out which part of the flow is the root cause. While many tools support stepping through the flow to find potential issues during development, how can one assure that the generated code keeps performing in a production or acceptance environment?

Without any additional configuration within Dynatrace AppMon the PurePath information already informs you about all bottlenecks, but it can be close to impossible to relate the bottlenecks back to the original flow created in the IDE. If one sees in AppMon that a specific query is executed 1000 times, or that a method is using a lot of synchronization or CPU time, how could one relate that back to one specific flow component used in the process?

One example of a solution which uses the above method to describe a process is Oracle BPEL Process Manager. The specific implementation explained below is related to Oracle BPEL Process Manager, but the thought process can be applied to countless other tools which generate code.

Oracle BPEL Process Manager

 In the following screenshot one can see all of the exceptions, response time and much more of a transaction, but the data cannot be related back to the developers of the application. The developers never wrote any code, they dragged and dropped elements in a graphical interface.

Out of the box PurePath

Using Application Monitoring from Dynatrace you can link the original flow to the generated code. When there is an exception thrown, a slow query, an unexpected end point being called or another problem within the application, it is possible to see which part of the process caused it.

By adding a sensor to a specific method that is part of the framework of Oracle BPEL we are able to follow the request through the different stages (Oracle BPEL terminology for one of the top layers of a flow):

Sensor configuration for stages

Once the sensor is added the PurePath tree will contain all of the stages which the request is using. Doing this it becomes clear which stage is responsible for which part of the PurePath.

PurePath with stage information

If information about which stage is executed is insufficient it is possible to go even deeper, to every individual component of the flow. To get that additional insight we need to instrument another method with a specific accessor.

Sensor configuration for components

After adding the sensor which captures the component names we can see each individual part of the flow in the PurePath. If there is a slowdown, exception, architectural issue or one of many other issues, we can pinpoint it to a single component with just a couple of clicks. This provides a similar insight as stepping through the flow during development, but for every single transaction in production.

PurePath with component information

Break open the black box and get in control of your applications, no matter if they are developed or generated!