Service Desk Practitioners Forum
cancel

Configuration Item population with Incident Generation

Highlighted
Michael Lutfi
Outstanding Contributor.

Configuration Item population with Incident Generation

Hello all,

I have set up OVO Unix 8.1 to forward events to SD 4.5 as Incidents successfully with the exception that I can not get SD 4.5 to correctly populate the Configuration Item field with the field ci which comes from OVO, which is actually mapped to Configuration Item with Reference to Search Code.

For the sake of debuggin I also made the CI mapped to another text field and the value that comes is correct.

Any ideas...on what could cause this strange behaviour.
17 REPLIES
Carol Hibbard
Acclaimed Contributor.

Re: Configuration Item population with Incident Generation

Can you show us what is coming across from OVO and then show us the CI that you expect it to match? Are you sure that your mapping is set up correctly to populate the CI field? Show us your config files. I have seen issues where the nodename in OVO is the fully qualified domain name and the name is SD is the shortname. Did you import your nodes from OVO to create your CI's?
Michael Lutfi
Outstanding Contributor.

Re: Configuration Item population with Incident Generation

Carol Yes I imported them from OVO directly using the standard template...I will take screen shots and post them shortly
Carol Hibbard
Acclaimed Contributor.

Re: Configuration Item population with Incident Generation

The default mapping of ovo message attributes to SD is such that ci=ovo_service_name or ci=NODENAME if the service field is empty. So if your messages have a service name as would be the case for the OSSPI messages, then the service name would be passed. If you have changed this such that the nodename is being passed, then you need to make sure that the nodename matches the NAME1 field for the desired CI using the default import file vpunix.

-------Default Mapping -----------------------------------------------------
from file: /opt/OV/sd/config/sd_eventins.pl

ovo message attributes passed in are: ('MSGID', 'MSGTEXT', 'INSTRUCTIONS', 'MAP_COLORING',
'NODENAME', 'SEVERITY', 'ANNOTATIONS', 'OBJECT',
'ORIGMSGTEXT', 'APPLICATION')

and processed as follows

# node is equal to the message service if not empty and otherwise the node name
# service information is stored in the MAP_COLORING field
$node=$vp_params{MAP_COLORING};
if ($node eq '') {
$node=$vp_params{NODENAME};
}

$exec_string = "perl /opt/OV/sd/ovo/bin/sd_event -f /opt/OV/sd/ovo/config/sd_eve nt.ini -v event_id=$vp_params{MSGID} description=\"$vp_params{MSGTEXT}\" information=\"Original message: $vp_params{ORIGMSGTEXT}\\nDetected by application: $vp_ params{APPLICATION}\\nObject in question: $vp_params{OBJECT}\\nAnnotations: $vp_ params{ANNOTATIONS}\" solution=\"$vp_params{INSTRUCTIONS}\" ci=\"$node\" impact= \"$vp_params{SEVERITY}\"";
Michael Lutfi
Outstanding Contributor.

Re: Configuration Item population with Incident Generation

Carol Please find attached the Import mapping for Incidents with highlight for Configuration Item....I don't think this is the issue. I am starting to really think I have bumped into a bug...
Michael Lutfi
Outstanding Contributor.

Re: Configuration Item population with Incident Generation

Carol that is not the issue. I have actually modified that part so that is actually only picks up the NODENAME variable, which I know is the server name.


I have also tried to Reference either Name1 or Search Code and neither work...
Carol Hibbard
Acclaimed Contributor.

Re: Configuration Item population with Incident Generation

Have you tried to map the ci to use the CI Name1 field as the Reference to Item? This is normally how it is configured.
Carol Hibbard
Acclaimed Contributor.

Re: Configuration Item population with Incident Generation

What is getting passed as the ci (looks like you should be able to see it in the Workaround field)?

What is the value in CI Name1?

What is the value in the CI Searchcode?
Michael Lutfi
Outstanding Contributor.

Re: Configuration Item population with Incident Generation

Please find attached a screen shot in which I show that ci field that is mapped to the text field Workaround is populated with a value that I know is the searchcode of a Configuration Item...as shown in another screenshot
Carol Hibbard
Acclaimed Contributor.

Re: Configuration Item population with Incident Generation

Are you using an Oracle DB for SD? If so, it is case sensitive and the lower case nodename shown in workaround would not match the upper case searchcode value. I believe that is why the default mapping matches on the Name1 field which would be in lower case if you used the default import mapping for your nodes from OVO.
Michael Lutfi
Outstanding Contributor.

Re: Configuration Item population with Incident Generation

Interesting I had the same suspicion earlier and I actually edited the perl file to make the $node variable changed to uppercase as it gets populated...see below:

$node= uc $vp_params{NODENAME} ;

And just for the sake of double checking I just tried it and once again it does not populate the Configuration Item but does populate the Workaround field with the name of the node but in Upper Case.
Carol Hibbard
Acclaimed Contributor.

Re: Configuration Item population with Incident Generation

Did you try using Name1 as the Reference to Item? Did it match?
Dennis Melchi
Trusted Contributor.

Re: Configuration Item population with Incident Generation

Michael,

The log file specified in /opt/OV/sd/ovo/config/sd_event.ini on the OVO server usually will indicate what Service Desk does not like. I would look at that first. Second look at the server log file on the Service Desk server. It may also indicate if there is an error in one of the fields you are attempting to pass via sd_event.

It looks like you are using Search Code as the CI mapping value so you will want to pass the node name in upper case. Make sure the CI Search Code does not have a fully qualified domain name and OVO does or if the other case is also true.

You may also want to try calling the sd_event command line manually on the OVO system to see what you receive for results.

I have run into an issue previously where sd_event on a Solaris 8 system would not read the ini file specified with the â f flag. I have not tested to see if this has been resolved in recent service packs. I just changed how I was calling sd_event to pass all the parameters that I was setting in the ini file.
Michael Lutfi
Outstanding Contributor.

Re: Configuration Item population with Incident Generation

I have tried to do the mapping to Name1 as well and even that does not work...
_________________
If you look at the some of the attachments I have attached on this thread you will notice that the "ci" sent over from OVO and the search code are identical...
_________________
I have checked to see if any messages appear in the log files and there is nothing there...both on the SD Server side and the OVO side...
Ruth Porter
Acclaimed Contributor.

Re: Configuration Item population with Incident Generation

Hi Michael,

Does it work if you type the command by hand?

Regards

Ruth
http://www.teamultra.net
Carol Hibbard
Acclaimed Contributor.

Re: Configuration Item population with Incident Generation

What happens if you check the box that the CI to SEARCHCODE should be used for Key binding in your import mapping?
Dennis Melchi
Trusted Contributor.

Re: Configuration Item population with Incident Generation

Michael,

Try running sd_event from the command line specifying all options in the command line instead of using the -f option. The issue I ran into did not produce any messages in the log file, it just didn't work using the -f option.

I'm assuming you have the SD agent installed on the OVO system and patched to the same version as the SD server.

Michael Lutfi
Outstanding Contributor.

Re: Configuration Item population with Incident Generation

You will not believe the solution:

History:

1) the mapping didnt work initially because the wrong variable was being sent from OVO
2) I mapped "ci" field to two different fields one of them being a text field so I can see what value is being passed
3) I corrected the perl file from OVO to send the correct value to SD
4) still the configuration item was not being populated whether i populated the Name1 field or the Search Code field

Solution:

REMOVE THE DOUBLE MAPPING OF CI TO MORE THAN ONE FIELD...apparently somewhere in the knowledge base is a documented issue with SD having a field mapped to more than one field.

special thanks to Stephannie Savoie from HP support for coming up with the solution...