sys_class_name not available to map

[tanya71]

while creating webservice transform map , I could not get the sys_class_name field in cmdb_ci table . That is the Class field is not showing in the dropdown to include in the mapping assist on transform map . It is not showing up on the webservice list of fields as well.experts urgent help please how to get the class field on cmdb_ci table on the webservice import set and/or include in the transform map?

[Community Alums]

sys_class_name isn't going to be available because you are transforming directly into a table, which removes the "need" to map to sys_class_name (it's being done already). If you need to do something like this with the transform map, probably in a run script:

var os = source.u_operating_system.toLowerCase();   
   
if (os.indexOf("linux") > -1){   
   
   target.sys_class_name = 'cmdb_ci_linux_server';   
   target.u_custom_field = "Custom value";         // insert value specific to linux servers in this row   
}   
else if (os.indexOf("windows") > -1){   
   
   target.sys_class_name = 'cmdb_ci_win_server';   
   target.u_custom_field = "Custom Value";           // insert value specific to windows servers in this row   
}   
else if(os.indexOf("unix") > -1){   
   
   target.sys_class_name = 'cmdb_ci_unix_server';   
   target.u_custom_field = "Custom Value";           // insert value specific to unix servers in this row   
}   

[david_legrand]

The sys_class_name field is available under the name "Class" into the "field map" records and it's very useful when you make one big import on the cmdb_ci table

This script is well working but will work the same into a "field map" script were you have to modify "target.sys_class_name" by answer.

But personally, I use to put the right sys_class_name into the excel / csv file from the beginning (it's just an habit, I could make the things on ServiceNow as well but this way, I'm sure everyone is using the same vocabulary on the future cmdb).

Regards,

[Community Alums]

Well I learned something today. I would argue that it's not something I would do though, since this is a WS import and not a spreadsheet. Not sure I'd want to add all those values to the source.

[david_legrand]

It's the good thing with ServiceNow, you can make things differently according the situation and the needs

For example, we could have a source (excel or web service) and then several transform maps or we could have several sources and several transform maps.

1st option: The customer is saying "I have a lot of classes AND I want to minimize the maintenance time in case of evolution for the ONE team doing the imports"

1. cmdb_ci for the main fields including the class mapping (and if I have to make an evolution on the "assignment group" field, I'll do it once for all)
2. cmdb_ci_service for the business service with a onBefore script making "ignore" if my current line isn't a business service
3. cmdb_ci_server for the servers...
4. cmdb_ci_server_linux ...

2nd option: The customer is telling me "I want to import data... BUT the TEAMS have to be very independent one from another" (server team from business service team...)

1. In that case, the right way to implement is having only "full transform maps" dedicated on the desired CIs (without using the cmdb_ci table)

And your very right with your argument, in your case, you might took the best decision. I usually say "The requirements and the constraints have to be the first source of info for the design, experiences come only after"

ps:I'm learning everyday as well