Service Mapping - Connection to Oracle DB endpoint is failing

[jan_at_te]

Folks,

doing a service mapping on a BMC Control-M Enterprise Manager app. As an entry point, I use TCP with host and port information. There is a pattern already available. Control-M Enterprise Manager is getting discovered and mapped. The deviation of the pattern and on how we use Control-M is that we use an Oracle instead of Postgres as DB management system hosting the DB for this app. However (i thought), I added a connection section to the pattern to connect to the ORA Instance. The ORA instance is running on a separate host. Host, Instance, Port and Schema are available through a config file. Within the connection section I read out this information and as for the last step, I added a 'Create Connection' operation with the following parameters:

Connection Type: application flow

Entry Point: Oracle Endpoint

Connection Attributes: host, instance, port and schema

Target CI Type: Oracle Instance[cmdb_ci_db_ora_instance]

Having the Discovery ran with the changes on the pattern is just recognizing the Control-M EM app, but not the connection to the ORA instance. The Discovery Log is showing my connection section as failed and is just giving me a 'name attribute was not discovered for entry point type cmdb_ci_endpoint_oracle_db'.

In the meanwhile, I hardcoded the connection attributes, but without any change on the result.

By adding just a TCP entry point on the DB host with the DB port is discovering me the awaited ORA Instance (there is just one instance running on the DB server). Does anyone have a clue why I do not get the connection established via the connection section?

Thanks and regards

Jan

[robertgeen]

Try getting rid of the target Ci type in the connection section create connection step. I find quite often it can cause it to have some issues sometimes. This shouldn't be the reason but just a though. Outside of that for the table that it's referencing as needing a name can you go to the table area in ServiceNow and look at that table and see if name is required? If it is it shouldn't be and this could be the reason why (maybe someone accidently set it as being required for the entry point type).

[jan_at_te]

I am running out on ideas in the meanwhile. You gave me new tracks I can follow, but all of them are ending without a breakthrough.

I removed the target CI. I looked for the name attribute and yes it is mandatory as it is inherited from the major CI table. I even set this as mandatory = false and even set a default value. All without any (positive) impact.

What is always going through my thoughts: What is the difference of having an entry point which is pointing on this host and the listening port and of having a connection step defined within a pattern which is (also?) using the Ora DB endpoint? As the first thing is working, Ora as app is identified and the instance is also recognized, does the other thing perish with the only hint that the name attribute was not discoverable. For me, it does mean that both are using different processes.

[robertgeen]

So the reason to do it in a connection section is because you should be pulling the information out of a configuration file so it's dynamic. When you do it via an entry point you are telling it the server but if it ever switches off of that server the map won't auto update (which is the whole purpose of Service Mapping). If you made it so name isn't a required attribute (which it shouldn't be) then I would recommend opening a HI ticket because there could be a bug somewhere that is causing this. Either way if you are happy with just adding the entry point then by all means go ahead :).

[Michael Skov2]

What does it look like when you actually test the connection steps?

[jan_at_te]

It looks like the same as yesterday. What is the intention behind your question?