Good Morning Jorge.
From the SM 17.1 WIKI landing page: https://docops.ca.com/ca-service-management/17-1/en/
Please search for 'integration'.
And then from the resulting pages, you could find your way for this.
I also have the following information available for you on this subject:
https://cawiki.ca.com/display/CASupport/SDM-Catalog+Integration
>Link: SDM - Catalog Integration
Catalog-SDM integration using Self Service integration option(no PAM):
The 'Report an Issue' offering. Which uses native integration between Catalog – SDM.
No PAM is needed here.
Here’s what we know about this over couple of cases that we ran into:
1) Any request in Catalog (against this offering) would create a ticket in SDM automatically.
Performed via Events/Rules/Actions in Catalog and SC-SDM integrated java processes.
The 'Report an Issue' service invokes the following Java action to create the SDM ticket:
Administration > Events-Rules-Actions > Request/Subscription Item Change
> When Category is Service Management Content and Status is Pending Fulfillment
> Create Incident
This is based on the service option category.
(e.g. Catalog > Service Offerings > Option Groups > Report an Issue
> Definition > <Edit> > Category) set to 'Service Management Content'.
2) Associated SDM’s ticket contains a reference to Catalog request via: external_system_ticket attribute in SDM.
It’s of the format: casc-<catalog_item_id>-<catalog_request_id>
3) From now on, SDM’s Catalog Sync Daemon (see further below on this page) is supposed to keep:
activity log updates synced to Catalog (SDM has new options for CA SC, see further below on this page)
attachments in SDM should sync to Catalog as a link
status of SDM tickets should be synced to Catalog too. (one of them is – if SDM ticket is closed, then Catalog request should be set to Fulfilled/Completed).
NOTE: ONLY CLOSED status in SDM triggers a Status update in Catalog.
Any other status changes are NOT synced.
This is a limitation of the integration at this time.
For all other statuses sync to work, you would have to create a custom PAM process to synchronize those statuses.
Note: In SDM: itsm_msg_queue trigger on alg object does this magic apart from catalog_sync_daemon’s java code.
To debug the messages being sent from SDM To Catalog, with in SDM check Debugging section below.
4) SDM’s catalog sync daemon uses some internal messages of the format "123456@@@@@"Comments from SDM"@@@@@CASMAdmin".
(Catalog request#, followed by comment in SDM, followed by userid separator is @@@@@)
5) This message is inserted into itsm_msg_queue table and then the message is processed by SDM’s Catalog sync daemon.
If it is successful, the record is deleted from the table.
If not, we keep retrying until retry count/interval is reached.
Note: To debug this In Catalog check Debugging section below.
If the message format was changed for some reason the integration will stop functioning.
In a similar way, if the user updating SDM request doesn’t have appropriate privileges on Catalog Request, the sync won’t happen.
SDM-Catalog integration when using PAM:
Following is the request lifecycle I verified locally with Catalog raising Service Desk change orders based on the OOTB integration:
Catalog request Submitted > Pending Approval > Approved (via Approve/Reject button) > Pending Fulfillment
> Check Availability > Filled from Inventory (via Fulfill button) > SD Change Order Opened
At this point the SD change order is raised via the /SLCM/FilledFromInventorySDM PAM process
in either SLCM.HWFFI/SLCM.SWFFI change categories
which have the following PAM process associated under the 'Workflow' tab:
/SDM/HWSW_FilledFromInventory Process
So once the change order is raised this process will be invoked which creates an approval task in PAM
(Operations > Links > Tasks > All Tasks).
Once this task is set to 'Approve' the above process will login to Catalog and update the request status to 'Fulfilled'
and also update the change order to 'Closed'.
Catalog will then update the status automatically to 'Completed'.
In order for '/SDM/HWSW_FilledFromInventory Process' to complete
'/SDM/SDM_GlobalDataset' needs to contain valid Catalog Service Delivery Administrator user credentials
within the 'Login Parameters' folder.
======================================
1) SDM Catalog sync daemon is a Java based program on SDM side.
2) SDM's Catalog options in Options Manager -> CA Service Catalog:
casc_aty_sync CA Service Catalog LOG,ESC,RE Installed
casc_endpoint CA Service Catalog http://CatalogHostName:8080/usm/services Installed
casc_integrated CA Service Catalog Yes Installed
casc_session_timeout CA Service Catalog 20 Installed
casc_user CA Service Catalog CASMAdmin Installed
casc_user_password CA Service Catalog <encrypted pw>
casc_ws_retry CA Service Catalog 20 Installed
3) usp_itsm_msg_queue table
- The usp_itsm_msg_queue table is used by SDM to store messages that SDM needs to send to Catalog via web services.
- Messages include ticket activity logs and attachment details.
- Once the messages are sent, the records from usp_itsm_msg_queue should be deleted from the table (so no need to archive/purge this table, as SDM should take care of this).
- On startup, SDM will check for messages that haven’t yet been sent or synced to Catalog. The records with the status column as 1 are currently not synced.
4) Close attention needs to be paid to the act_log entries that go into an SDM ticket.
Example, you have Test Groups with Hundreds of members in them.
Each member have a valid Email address, but Notification Method is set to NULL on each one of them.
A simple Comment made to an SDM ticket could potentially now create hundreds of notification error messages recorded to the SDM Act log.
Now these all need to be synced to Catalog.
This could cause domsrvr to cache/crash.
5) Out of box, the external_system_ticket should be in the format: CASC-<subscriptiondetailid>-<requestid>.
If this is changed somehow, the catalog sync daemon wont be able to sync comments back and forth properly.
6) Debugging:
SDM: do the following on the background (or Primary) machine
1. Open the log4j.properties file under NX_ROOT/site/cfg folder.
2. Change the line:
log4j.rootCategory=Error, jstdlog
to
log4j.rootCategory=Debug, jstdlog
3. Also add this line at the end of the file:
log4j.logger.com.ca.ServicePlus.CatalogSync=debug, jstdlog
#If needed add below line too, which produces additional debug info
log4j.logger.com.ca.ServicePlus.slump=debug
The above change is not effective until restart of Catalog Sync daemon (or restart of SDM).
Here's one way to kill the java program related to the Catalog Sync daemon in SDM
(it restarts itself immediately and starts processing any backlog left behind since kill)
pdm_status|findstr /i SYNC
## this shows something like below
PDM CATALOG SYNC DAEMON (pdm_ Running SDMHostName 8684 Fri Nov 11 11:11:29
In the above output, 8684 is the Process ID for that daemon on that server.
Keep in mind, in case of AA this is on the BG Server.
C:\>pdm_kill 8684
Killing pid( 8684)
Process id 8684 terminated
The above restarts the catalog sync daemon.
4. Run the cmd on console:
pdm_logstat -f itsm.spl TRACE
pdm_log4j_config -f SDM_WEB -l DEBUG -a -s 30MB
Note: Wait a minute for it to be effective.
Obtain the NX_ROOT/log zipped from all the needed boxes.
Catalog:
5. C:\Program Files\CA\Service Catalog\view\conf\log4j.xml.
Backup this file and modify logger names below to the values below.
Wait a minute for it to be effective.
<logger name="com.ca">
<level value="TRACE" />
</logger>
<logger name="com.ca.usm">
<level value="ALL" />
<appender-ref ref="memory" />
</logger>
<logger name="com.ca.usm.util.ViewManager">
<level value="DEBUG" />
</logger>
<logger name="com.ca.usm.producer.DocumentGenerator">
<level value="DEBUG" />
</logger>
6. Obtain USM_HOME\logs\view.log
Kind regards, Louis van Amelsfort.