Tips for customizing groovy scripts
This section provides some tips about customizing Groovy scripts. It contains a few selected examples of what you can customize. To see further items that can be modified, see the configuration section of a Groovy script.
In the configuration section of the Groovy script, you can define and modify the attributes that are to be synchronized between OMi and SM. The configuration section of the Groovy script also contains the default value mappings for lifecycle state, severity, and priority. You can also modify these, and it is possible to define the mappings for in-going and out-going requests differently.
More advanced configuration can be done in other parts of the Groovy script if required.
The beginning and the end of the configuration section of the Groovy script is marked as follows:
//
// configuration section to customize the Groovy script
// BEGIN
...
...
//
// configuration section to customize the Groovy script
// END
Note Modifications to Groovy scripts are not overwritten by patches and hotfixes. Your customized version of a script will remain after an update or a patch. If you want to use the newer version of a script, make a copy of your version, revert back to the predefined version, and then reapply your changes.
The mapping from OMi to SM is compliant to BDM 1.1 incident web service specifications. The mapping of the BDM 1.1 incident web service to SM is specified in SM in the BDM Mapping Manager. For more information about the BDM Mapping Manager, see the BDM Mapping Manager section of the HPE Service Manager online help.
Controlling attribute synchronization
You can control how updates to certain attributes are synchronized between OMi and SM by setting some Boolean variables to true or false.
Examples:
-
SyncAllPropertiesvariable. By default, it isfalse. If you set it totrue, all properties will be synchronized in both directions. The other variables will be ignored. -
private static final SyncTitleToSMOnUpdate = false;This line of the Groovy script disables the synchronization of changes to the title made in OMi to SM.
-
private static final Boolean SyncTitleToOPROnUpdate = false;This line of the Groovy script disables the synchronization changes to the title made in SM to OMi.
The title is a required attribute in SM, and it is set, independently of the flags above, using the title given in OMi during the creation of the incident.
Mapping OPR Lifecycle States to BDM Lifecycle States
Individual OPR event state and SM incident status changes may be selected for synchronization. Out of the box, only the "closed" state is synchronized in both directions. To change this behavior, add the desired states to the appropriate list, SyncOPRStatesToSM or SyncSMStatusToOPR .
Examples:
-
private static final Set SyncOPRStatesToSM = ["closed", "in_progress", "resolved"] -
private static final Set SyncSMStatusToOPR = ["closed", "resolved"]
In the example, the OPR event lifecycle states closed, in_progress, and resolved are synchronized to the SM incident status, and SM incident statuses closed and resolved are synchronized to the OPR event state.
Note The special state "*" denotes all states, so to synchronize all OPR event states to the SM incident status property, specify the following:
private static final Set SyncOPRStatesToSM = ["*"]
Additionally, two maps are used to specify the mapping of the OPR event lifecycle state to the BDM incident status. The maps are named MapOPR2SMStatus and MapSM2OPRState. Out of the box, all possible states have a mapping.
Examples:
-
private static final Map MapOPR2SMStatus = ["open": "open", "in_progress": "work-in-progress", "resolved": "resolved", "closed": "closed"] -
private static final Map MapSM2OPRState = ["accepted": "open", "assigned": "open", "open": "open", "reopened": "open","pending-change": "in_progress", "pending-customer": "in_progress", "pending-other": "in_progress","pending-vendor": "in_progress", "referred": "in_progress", "suspended": "in_progress","work-in-progress": "in_progress", "rejected": "resolved", "replaced-problem": "resolved","resolved": "resolved", "cancelled": "resolved", "closed": "closed"]
Avoiding Errors with Large TQL Queries
If the Groovy script executes a TQL query that produces a large number of results, an error message appears informing you about the TQL query result exceeding the size limit. As a consequence, the integration event is not sent. It is possible, however, to increase this limit by modifying the value of the tql.compound.link.max.visited.objects setting.
Note To check the default value of the tql.compound.link.max.visited.objects setting, from the JMX console, select UCMDB:service=Settings Services, and then locate the showSettingsByCategory method and enter TQL Settings as the category name.
To modify the value of the tql.compound.link.max.visited.objects setting, follow these steps:
- From the JMX console, select UCMDB:service=Settings Services.
- Click setSettingValue.
- Enter
tql.compound.link.max.visited.objectsas the name of the setting you want to modify and a new value for it.
Caution Increasing the value of the tql.compound.link.max.visited.objects setting also increases the load on the RTSM. Therefore, make sure to carefully consider how much to increase this value.
Syntax Errors
If you get a syntax error when customizing your Groovy scripts, you will get an event in the event browser with a detailed description of the error. In addition, you may view the opr-event-sync-adapter.log log file for information about how to resolve the error. You can find this log file at the following location:
<Gateway Server root directory>/log/opr-event-sync-adapter.log