The ports should be found using discovery not set as an input into a ucmdb xml file.
What I understood is that you are suggesting about the discovery ports and they should not set as an input in a xml file.
Here is a link to open an enhancement request : https://community.softwaregrp.com/t5/CMS-Idea-Exchange/idb-p/CMS_Idea
Consequently development team can check your idea and work on it.
This topic was escalated to Email Message on 12-01-2018 by Anonymous_User1.
If you find an open port on a remote machine then either you use a mapping file (what we use now) or you try to do an educated guess about what service is delivered via that port.
The second option is somehow done today by nmap to some degree with a relatively good accuracy. The side effect is that very few customers actually use nmap because in today's IT infrastructures it's considered a sniffing tool or a possible security problem.
According to Microfocus
“It depends on the access you have to the servers hosting Oracle”
If you have shell access to the server, and are able to run the Host Applications by Shell job (with IP Service Endpoint collection turned on), you should not have to identify the Oracle ports in the portnumbertoportname.xml file
If you do not have shell access to the server, you can still discover Oracle, via the Oracle by SQL job, but a prerequisite for this discovery is to run the TCP Port job, which DOES require the Oracle ports be documented in the portnumbertoportname.xml file.
I understand your frustration because Oracle discovery is really messed up. There is definitely some issue with discovering the TNS Listeners from several jobs. At the same time you have the Oracle Connection by Shell, which doesn't use SQL statements issued from the probe and it does NOT require to specify the ports in the portnumbertoportname.xml. I suppose the TCP Ports job is there to guarantee that the DFP has network connectivity to the TCP ports of Oracle. In other case you may find thousands of local ports opened, but not available through the network.