The Oracle Concurrent Manager manages the traffic from Oracle Forms Server to the Oracle Database.
Our decoder analyzes the traffic from client workstations/load balancer to the Oracle Forms Server.
The response time lag and other metrics (from the traffic starting from Oracle Forms Server to the Concurrent Manager to the Oracle Database) are taken into consideration by the decoder.
However, the decoding of the traffic is done prior to the Concurrent Manager.
So, we don’t decode traffic from the Oracle Forms Server to the Oracle Concurrent Manager, but we do accommodate Oracle Forms traffic that uses the Oracle Concurrent Manager.
Thanks for confirming that 'Generic with transactions' analyzer should be used for 'Oracleforms to Conc Manager'.
Is there any plans to decode the transactions fired from Oracle Forms to the Concurrent manager?
Would you also know what Transactions/Calls can be expected from OracleForms to Concurrent manager and whether reporting these calls would be useful/valuable to either the IT Admin or Operations Personnel or OForms Developers?
before telling what we would plan for CM, we need to analyze it deeper, as until now we didn't have explicit requests for monitoring this tier with DC RUM. Packet traces from the customers's environment would greatly help, so looking at Praveen here for help.
CM main role is load balancing the program calls, so on a very high level it resembles a load balancer in the web application architecture. However, even if we successfully monitored both sides of the CM, we should not assume we have a complete performance monitoring offering for CM. agent less technology will not know what are internal CM's contingencies, e.g. Queue length of programs/procedures/calls waiting to be executed. We will not follow transactions through either.
So shortly put, DC RUM can provide only auxiliary value for CM monitoring and adding this tier should be considered a nice to have extension to main value of EUE