cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Monitoring Oracle Forms Application in DCRUM

This might sounds a bit silly, but um,

If there is Oracle Form Application with LB or Web, the decode used should most probably be OF over HTTP? or should most probably be HTTP? Or it depends on the design?

All this while I am monitoring Oracle Forms Application with only App Tier and DB Tier. You can't really go wrong with the choice of decode here in this two-tier scenario.

Just recently, I added another OF application into DCRUM which is 3 tiers architecture(lb-app-db). App tier and DB tier are just fine, but lb tier are always just 'NA:Start' and 'All other operation'.

This client site I've been working with has a ....'notorious' history of mis-configured their port-mirroring, so I thought this time it would be the same too, and I just keep on asking them to check on it.

So, we are in a stalemate, then I decide to temporary use the HTTP decode for this lb tier, for now, so that the home dashboard wouldn't be full of black color bar (undecrypted/failed transaction).

The URLs shown in the above screenshot seems to conform with the theory I learnt through googling? I just wonder is it possible that in the real world, there is some cases that is unlike what the theory preached ( For example, in this context I am wondering is it possible that the OF traffic which runs on top of HTTP, in some rare situation would hit the front-end lb tier instead of hit the app tier)

I wanted to tell myself with confidence that, using HTTP/S decode (instead of OF-over-HTTP/S decode which I initially thought) on the lb-tier, I didn't miss out any important traffic.

Hence, post it here to see if anyone that ever configure OF application with more than 2-tier that can share experience/insight. (Or perhaps share any link of good read about this)

2 REPLIES 2

Krzysztof_Ziemi
Dynatrace Pro
Dynatrace Pro

Hi,

Which AMD version do you use? If it's not the DC RUM 2017 (which features the HS AMD), then move to 2017 ASAP. The reason is that the 12.4 and earlier Classic AMD versions had limitations in the OF over HTTP decode - effectively only one OF data feed could have been monitored with this decode, so either front or back of LB, but not both.

DC RUM 2017 AMD has a completely new architecture and such limitations don't exist anymore. And it has another important advantage: Forms parser is an integral part of the HTTP decode, which in practice means you always use the HTTP(S) decode and configure per-URL whether URL parser or Forms parser has to be used to dissect operation names. Lots easier than before.

Best regards

12.4.14 and classic, I will plan an upgrade agai ASAP.

Thanks for that.