ServiceNow集成指南：企业系统互联核心技术

需积分: 10 184 浏览量更新于2024-07-24 收藏 6.2MB PDF 举报

“Service Now 整合指南” Service Now 是一个强大的企业级服务管理平台，它提供了广泛的集成能力，使得与其他第三方应用和数据源的交互变得简单。本指南将深入探讨 Service Now 集成的关键方面。一、集成概述 Service Now 可与众多第三方应用程序和数据源无缝对接。最常见的集成包括配置管理数据库（CMDB）、事件管理、问题管理、变更管理、用户管理和单点登录（Single Sign-on）。集成方法多种多样，如 Web Services、JDBC、LDAP、Excel、CSV 和电子邮件，以及利用 SOAP、REST 或 WSDL 的行业标准技术。此外，还可以通过 MID Server 进行 API 和命令行集成。二、集成技术 Service Now 平台基于服务导向架构（SOA），这意味着所有数据对象都可以使用 Web 服务实现双向数据级集成。这种接口直接且动态，因为对现有对象的任何修改以及新创建的对象都会自动发布为 Direct Web Service。除了直接的 Web 服务外，还可以通过映射 Web 服务实现间接的集成，这里会使用转换地图将接收到的 Web 服务数据转换为最终目标格式。三、常见集成案例 1. **配置管理数据库（CMDB）**：CMDB 的集成允许 Service Now 与组织的 IT 资产管理系统连接，确保资产信息的实时同步。 2. **事件管理**：集成可以帮助自动化事件报告和响应流程，例如与监控工具的联动，当系统发生异常时，自动在 Service Now 中创建事件。 3. **问题管理**：与问题跟踪系统的集成可以提升问题解决效率，确保问题的完整生命周期管理。 4. **变更管理**：与项目管理工具集成，确保变更请求和变更过程符合规定流程。 5. **用户管理**：通过 LDAP 或单点登录集成，可以简化用户身份验证和权限管理，提高安全性。 6. **数据导入导出**：Excel 和 CSV 集成方便批量导入和导出数据，进行数据迁移或分析。四、MID Server MID Server 是 Service Now 提供的一种轻量级代理服务器，用于在 Service Now 实例与外部系统之间进行安全、高性能的通信。它可以执行脚本、监控远程系统并处理复杂的集成任务，尤其是在防火墙限制或需要本地系统访问的情况下。五、API 和 RESTful 集成 Service Now 支持 RESTful API，这使得开发人员能够轻松地构建自定义应用，与 Service Now 平台进行交互，实现数据的获取、创建、更新和删除等操作。总结，Service Now 的集成能力是其强大功能的关键组成部分，它为企业提供了一个统一的平台来管理 IT 服务，并与其他关键业务系统协同工作，从而提升效率和一致性。通过理解并熟练运用这些集成技术和工具，企业能够构建更高效、更连贯的服务管理流程。

Direct Web Services

__last_row Instruct the

results to be

limited by this

number of

records, from

the beginning

of the set, or

the

__start_row

value when

specified.

When used

with

__first_row

has the effect

of querying

for a window

of results. The

results are less

than the last

row number,

and does not

include the

last row.

<__last_row>500</__last_row>

__use_view Specify a

Form view by

name, to be

used for

limiting and

expanding the

results

returned.

When the

form view

contains deep

referenced

fields eg.

caller_id.email,

this field will

be returned in

the result as

well

<__use_view>soap_view</__use_view>

Perl Example - querying all incidents 5 records at a time

The following example will query the demo instance, querying all incidents, ordering by the number field, and

retrieving only the first 5 records. You can see by this example that you can easily extend this example to retrieve a

set of predefined records, n number of records each query, simulating a windowed querying client. Using a

windowed query mechanisms overcomes the default limitation of only getting a maximum of 250 records per query.

#!/usr/bin/perl -w

#use SOAP::Lite ( +trace =>; all, maptype => {} );

use SOAP::Lite;

Direct Web Services

my ($result) = @_;

if ($result->fault) {

print "faultcode=" . $result->fault->{'faultcode'} . "\n";

print "faultstring=" . $result->fault->{'faultstring'} . "\n";

print "detail=" . $result->fault->{'detail'} . "\n";

}

Return Display Value for Reference Variables

When you are getting a record from a get or getRecords function you will be returned all the fields associated with

that record. The fields are often reference fields that contain a sys_id for another table. The OOB (Out Of the Box)

behavior is to return the sys_id value for those fields. However, if you would like the display value for the field to be

returned you have two options:

1. Add the property "glide.soap.return_displayValue" to your system properties, and every soap request will return a

display value for a reference field.

2. Add the parameter "displayvalue=true" to your SOAP request URL, and soap requests with that parameter will

return a display value for a reference field, instead of the sys_id. Your WSDL and SOAP URL would look as

follows:

https:/ / instance. service-now. com/ incident. do?displayvalue=true& amp;WSDL

https:/ / instance. service-now. com/ incident. do?displayvalue=true& amp;SOAP

3. Add the parameter "displayvalue=all" to your SOAP request URL, and soap requests with that parameter will

return a display value for a reference field, in addition to the sys_id. The response element name for the display value

field will be prefixed with "dv_", eg. "dv_caller_id".

Retrieving Journal Entries

To get the contents of a journal field, make a second soap request against the sys_journal_field table to pull the

appropriate journal records back for the record in question.

The URL for the WSDL would be in the following format

https://instance-name.service-now.com/sys_journal_field.do?WSDL

To retrieve the journal entries, you will first need to query the incident for its sys_id value and then supply it as the

element_id value in a getRecords call. To sepcify records only for the "comments" field, specify the value

"comments" for the element field. For example, a SOAP request would look like the following.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:sys="http://www.service-now.com/sys_journal_field">

<soapenv:Header/>

<soapenv:Body>

<sys:getRecords>

<element>comments</element>

<element_id>9d385017c611228701d22104cc95c371</element_id>

</sys:getRecords>

</soapenv:Body>

</soapenv:Envelope>

Direct Web Services

Compatibility for Clients Generated from WSDL

Specifying a Unique Namespace for each Table

With the Berlin release, the property glide.wsdl.definition.use_unique_namespace ensures that

each table's Direct Web Service WSDL has a unique targetNamespace attribute. This property is true by default,

which requires a table's Direct Web Service WSDL to use a targetNamespace value of

http://www.service-now.com/<table name>. When false (or when the property is not present), all tables use the

same targetNamespace value of http://www.service-now.com. Since all tables also share the same operation names, a

Web Service client attempting to consume more than one ServiceNow Web Service would be unable to differentiate

between requests between multiple tables. Using a unique targetNamespace value allows Web Services clients to

distinguish requests between multiple tables.

For example, the DIrect Web Service WSDL for the incident table uses this targetNamepsace value.

<wsdl:definitions xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"

xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"

xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"

xmlns:tns="http://www.service-now.com/incident"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"

xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"

targetNamespace="http://www.service-now.com/incident">

<wsdl:types>

<xsd:schema elementFormDefault="unqualified"

targetNamespace="http://www.service-now.com/incident">

elementFormDefault

ServiceNow's WSDL schema by default declares an attribute of elementFormDefault="unqualified". This

attribute indicates whether or not locally declared elements must be qualified by the target namespace in an instance

document. If the value of this attribute is 'unqualified', then locally declared elements should not be qualified by the

target namespace. If the value of this attribute is 'qualified', then locally declared elements must be qualified by the

target namespace.

However, this is incompatible with the way clients generated from WSDL (.NET, Axis2, webMethods, ect.) process

the embedded schema, it removes the schema namespace as a result, making the web service response unparseable.

To overcome this compatibility issue, a boolean property called

glide.wsdl.schema.UnqualifiedElementFormDefault is introduced. This property has the value of true by default,

setting it to false will make clients generated from WSDL able to parse the return value of the web service

invocation. You can modify this property using the Web Services properties page at System Properties > Web

Services

剩余208页未读，继续阅读

wwwww12345

粉丝: 0
资源: 19

ServiceNow集成指南：企业系统互联核心技术

ServiceNowIntegration:CIC和ServiceNow之间的集成

terraform-servicenow-integration-2

Ansible Tower如何和servicenow集成

servicenow使用教程

servicenow教程

servicenow开发

service now 接口

ServiceNow怎么创建API用户

ServiceNow CRQs

ServiceNow

最新资源