T-Systems customers can now seamlessly integrate their ServiceNow instance into T-Systems with ease.
Created from the ground up to allow you to take advantage of your T-Systems provided services from within your own ServiceNow instance, the T-Systems Connector removes the complexity, effort, and cost involved in custom integration.
Incidents can be communicated with T-Systems and remain fully synchronized, including all notes and attachments, bi-directionally over the interface until the Incident is resolved and closed.
Service Catalog content, created specifically for each customer, can be made available in your instance. Any requests made from this content will be sent directly to T-Systems for fulfillment, with the Request and Requested Item kept updated throughout the fulfillment process. The T-Systems Connector allows you the flexibility to place your own approval process on the requested items, making sure you stay fully in control of your process.
Any CI’s created or modified for you by T-Systems will be synchronized back into your CMDB for your visibility and use in Incident Management and Request processes.
Because no two ServiceNow implementations are the same, the T-Systems Connector is fully configurable, allowing it to adapt to your process, not the other way around.
T-Systems connector application is currently tested by using ServiceNow forms and lists views. Workspace views are under investigation, but not yet tested.
Connect a ServiceNow instance to the T-Systems internal Enterprise Service Bus
Minor Changes:
Enhancement:Attachment should be transferred during Retry
Fixed the issue where the attachment was not being transferred after a retry.Updated script include "bondedAttachments" and "MessageStreamV2".
Enhancement: Adding T-Connector version information in the XML
The T-connector version information has been added to the routing node for each outbound message triggered by the T-connector for all processes.Updated all soap message Function for T-Connector and script include "AccessControlUtils"
Enhancement: Implement the Logging Mechanism in T-Connector for CHM2CHM part 2
Logging is added to the connector log table incase of function break during processing, Only added for ChangeToChangeManagement
Updated script include "TSInboundSOAPMapping","CHM_implementationConfirmReply_in","CHM_approvalReply_in" and "CHM_implementationDocReply_in" and choice list "Log.Status".
Enhancement: Implement Cleanup Utility for T-Connector CI Staging Data
Added a property and a scheduled job to handle the cleanup activity on Demand, controlled by connector property ‘core.delete.cmdb_conversation.active’ and scheduled job name ‘TSI Clean up CMDB Conversation Scoped’ for conversation table in T-Connector.Byfeault this scheduled job will be inactive.Customer needs to activate it and update the property to decide the days for data cleanup.
Bug Fix:T-Connector:Customer ID and data issue during retry mechanism
Fixed the issue of user context switch during retry mechanism in t-connector.Updated Script include"errorResponse".
Bug Fix:T-Connector: Error handling issue Resolved async error case and incoming error case
The following logic has been implemented to update the assignment group, state, and ownership in case of asyc error handling:
Ownership Update
Ownership is updated based on the value received in the ownerSystem attribute through the MessageStreamV2 script.
Remote Group Assignment Handling
If current ownership is not local, the assignment group is mapped to the default remote group value specified in the newly created connector property incident.default.remote.group. The value should correspond to the TSI remote group.
Local Group Assignment Handling
If current ownership is local, the assignment group is mapped to the value received in the OpnedGroup attribute. If this attribute is empty, the assignment group defaults to the value defined in the connector property incident.default.sender_group.
State Error Handling on Resolution
If an incident is resolved but an error is returned from OTIP, the state is reverted based on the value specified in the property incident.errorhandling.state
Updated script include "errorHandler","TSC_error_in","TSC_incidentData_in".
Bug Fix:T-Connector customers sometimes facing issue for inbound communication processing.
Fixed the issue where the system was returning an "inactive process" error even though the process was active. Updated script include "errorHandler","TSC_error_in","TSC_incidentData_in".
Bug Fix:Worknote is not updated during async error case when creator systems is not customer for incident
Updated the logic to use causingMessageId from the Routing node, as it always contains the SC3 unique ID.So the records fetched correctly to update the work note.
Updated script include "errorHandler","TSC_error_in","TSC_incidentData_in".
Bug Fix:Current.worknote is not working correctly
Updated Current.worknote to use current.work_note.getJournalEntry(1) to properly fetch the latest work note from the record.
Updated business rule "Message exchange triggering".
Bug Fix: Synchronous response is not showing correct value in Receiver ID for CHM2CHM
Fixed the issue for sync response generation for CHM2CHM.Updated Script include "CHM_approvalReply_in","CHM_implementationDocReply_in" and "CHM_implementationConfirmReply_in"
and "TSI_SyncResponseHandling".
BugFix:CHM2RITM - infinite possibilities for change approval
For CHM2RITM Functionality retry will only be working when Operation is "createRfC", for other operations if outbound error occurred then retry won't work.Updated script include "errorResponse".
BugFix:Incident is not getting autoclosed after 30 days
AutoClose should work when ticket is in Resolve state and incident Owner system is same as senderName for integrated incident via T-Connector. Hence as per OOB BR ticket should autoclose based on Property "glide.ui.autoclose.time" .Updated script include "connectorAPI".
Note: For mapping and property data related to this version,please connect with your T-Systems point of contact.
- ITSM
- The following plugins are recommended to be installed prior the T-Systems Connector app in order to support CMDB classes. However, the specific classes use will depend on the customer contract. These plugins are required to support the cross-scope privileges functionality:
- CMDB CI Class Models
- Expanded Model and Asset Classes
- Discovery and Service Mapping Patterns
- Cloud Provisioning and Governance: Terraform Connector
- Cloud Provisioning and Governance: Google Cloud Connector
- CMDB Mainframe
- CMDB Telecom CategoryCMDB Test Equipment