Upgrading callouts
Callouts attached to APIs are never automatically upgraded, although BMC attempts to preserve API backwards compatibility to ensure that an upgrade does not render callouts invalid.
The following information is provided in this topic:
CLM API backward-compatibility analysis
BMC has identified the following backward-compatibility issues when you upgrade to 4.5 or later. If you have TrueSight Orchestration (TSO) based customizations created for the following attributes and API’s, they probably will not work "as is" after you finish the upgrade. You must update the TSO-based workflows and your customizations accordingly. The following table lists the backward-compatibility issues when you upgrade from 4.0.x to 4.5 or later:
Class name | Operation | Callout type | Attribute | XPATH | Attribute Type | Description |
|---|---|---|---|---|---|---|
Virtualguest | Destructor | Pre | subnet | VirtualGuest.VirtualGuest. | string | Attribute missing post upgrade |
Virtualguest | Destructor | Post | subnet | VirtualGuest.VirtualGuest. | string | Attribute missing post upgrade |
Networkconnector | Destructor | Pre | subnet | NetworkConnector.VirtualGuest. | string | Attribute missing post upgrade |
Networkconnector | Destructor | Post | subnet | NetworkConnector.VirtualGuest. | string | Attribute missing post upgrade |
Finding the actual XPATH from the reported XPATH
You can find the actual XPATH from the XPATH listed in the previous table. In several other cases, the XPATH is even longer, separated with multiple periods (for example, NetworkConnector.ServerNetworkInterface.Network.NetworkContainer.LoadBalancer.LoadBalancerNetworkInterface.Network.LogicalNetwork).
The XPATH consists of a <CsmRequest>//<OperationParameters> tag that you can use in your search. Under <OperationParameters>, there are multiple <entry> tags.
The first value in the XPATH (for example, Virtualguest) represents the name of the cloud class and you can ignore it to calculate the XPATH. You might not see additional tags following Virtualguest. This indicates that the parameter is directly available at XPATH <OperationParameters>//<entry>//<string>.
In the first issue listed in the previous table, following VirtualGuest is a dot and then VirtualGuest. This indicates that, under <OperationParameters>//<entry>, there is a <CloudObject class= “VirtualGuest” name=” VirtualGuest”> tag. This again includes another cloud object <CloudObject class= “ServerNetworkInterface” name=” ServerNetworkInterface”> and the required parameter (IPAddress) is available under it.
As a result, the actual XPATH will be <OperationParameters>//<entry>//<CloudObject class= “ServiceOfferingInstance” name=” ServiceOfferingInstance”>//<entry>//<string>.
This analysis holds true for a provided XPATH that has more than one dots in it.