专利名称：用于业务网络管理发现和合并的系统和方法
技术领域：
一些实施例涉及业务(business)网络管理。更具体地，一些实施例与来自多个源的数据和元数据的发现和/或合并相关联，以创建系统和应用彼此集成的集成网络，并且从业务处理角度描述它们之间的交互。
背景技术：
企业内的集成开发可能要求对现有应用、系统、和/或接口的理解，以方便以一致的方式在它们之间进行通信。例如，集成中间件应用可以使能应用到应用(“A2A”)集成、业务到业务(“B2B”)集成、和/或电子数据交换(“EDI”)通信。这些中间件应用可以让应用实现面向服务的体系结构(“S0A”)和事件驱动体系结构(“EDA”)原理(principal)，并帮助组织(orchestrate)跨越企业内的不同应用的业务处理。在一些客户景观(landscape) 中，还可能存在多种软件实例(来自多个软件卖商)执行这样的任务。例如，软件实例可以被布置为中央集线器或者嵌入在应用系统中。为了帮助方便集成开发，可以通过在客户的景观中描述系统和应用(包括那些系统和应用的各种表现)以及经由中间件应用在它们之间的集成来制定(map out)网络。然而，创建这样的网络图或景观可能是耗费时间并且是容易出现错误的处理。例如，从技术和业务角度两者而言，集成中间件应用可能不提供景观的准确视图(view)。这样视图不仅在操作网络时是有用的，而且对于实现未来的网络改变和/或增强而言也是需要的。
发明内容
因此，可以根据这里描述的一些实施例提供用于自动和有效地确定业务处理景观的方法和机制。
图1是根据一些实施例的业务网络管理景观的框图。图2示出根据一些实施例的业务网络管理景观。图3是根据一些实施例的包括可以探索网络的网络管理服务器的系统的框图。图4是根据一些实施例的业务网络管理处理的流程图。图5示出根据一些实施例的合并的网络模型。图6示出根据一些实施例的另一级的合并的网络模型。图7是根据一些实施例的合并处理的流程图。图8是示出根据一些实施例的与系统相关联的传出和传入呼叫的图形。图9是示出根据一些实施例的来自系统的传出呼叫的图形。图10是示出根据一些实施例的系统通信的图形。图11是根据一些实施例的与系统相关联的融合(merged)的图形。
具体实施例方式在企业内的集成开发可能要求对已有应用、系统、和/或接口的理解，以方便以一致的方式进行它们之间的通信。例如，集成中间件应用可以使能A2A集成、B2B集成、和/或 EDI通信。这些中间件应用可以让应用实现SOA和EDA原理，并帮助组织跨越企业内的不同应用的业务处理。在一些客户景观中，还可能存在多种软件实例(来自多个软件卖商)执行这样的任务。例如，软件实例可以被布置为中央集线器，或嵌入在应用系统中。为了帮助方便集成开发，可以通过描述客户景观中的系统和应用(包括那些系统和应用的各种表现)以及经由中间件应用在它们之间的集成来制定网络。例如，图1是根据一些实施例的业务网络管理景观100的框图。景观100包括许多互连的系统110。例如， 系统110可以包括彼此通信的业务应用和/或服务器。请注意，系统110的子集120、130、 140可以在业务意义上被分组在一起。例如，一个子集120可以与总部业务处理相关联，而另一个子集130与分配中心处理相关联。然而，创建这样的网络图或景观100可能是耗费时间和容易出错的处理。例如，从技术和业务角度二者来看，集成中间件应用可能不提供景观的准确视图。这样的视图不仅在操作网络时是有帮助的，而且还可以是实现未来的网络改变和/或增强所需要的。根据一些实施例，可以基本上实时地来构建关于从网络角度从不同类型的已有 (并且运行的)生产系统(例如，应用和/或中间件)搜寻的集成网络的信息，这是具有企业的每天的业务处理的最新信息。例如，集成网络可以定义为经由在物理硬件系统上运行的业务应用彼此交互的业务参与者的网络。例如，图2示出根据一些实施例的包括三个业务参与者220、230、M0(例如，分别对应于图1的子集120、130、140)的业务网络管理景观 200。根据一些实施例，可以基于已有应用和/或中间件系统中可用的信息为客户景观自动地构建这样的集成网络。例如，所述信息可以包括以下各项中的一些或全部应用系统概观(例如，与应用服务器或数据库相关联)、产品版本、连通性信息、在中间件系统或应用系统上运行的集成、接口、集成处理模型、操作数据、业务处理描述、业务角色和参与者、业务对话(conversation)、和/或业务协作。请注意，本实施例并不限于信息的这些示例。而且，在一些实施例中，可以准许一定量的操作者干预。也就是说，网络景观可以被“自动地”确定，即使当操作者提供一些信息时(例如，系统名称和别名)。请注意，当相同信息具有多种表现时(例如，由于信息在不同领域中的使用)，应用和系统的异质性(heterogeneity)可以成为因素。例如，关于系统的信息可以在应用和中间件系统中具有一个表现，对于IT操作具有另一个表现，并且作为处理建模的参与者具有再一个表现。还请注意，各种工具可以提供可用于构建网络景观的元信息。例如，系统管理工具、IT操作工具、监控和IT操作工具、根成因分析和事故管理工具可以分别收集监控和操作数据，以使管理者分解和操作系统。这些工具可具有一些受限的类似发现的能力，用于经由运行时间代理读取元数据和操作数据或监控专用应用或系统。集成中间件(例如，企业应用集成、企业服务总线、和/或SOA应用)还可以具有用于内容开发和操作的设计和管理工具。这些工具还可以创建元数据和/或方便已有信息的一些发现。这里提供的一些实施例在发现处理期间独立于各种源系统地将元数据带进
5(bring into)公共表现。然后，可以在合并处理中执行一组基于规则的算法，以识别该信息之间的类似性和关系。根据一些实施例，可以基本上以实时方式执行处理。虽然在任何给定时间点所述集成网络可以表示特定状态的信息源的快照，但是所述发现和合并处理可以随着时间而不断地执行(因为集成网络可能随着源被添加、去除或改变而持续地演进)。业务网络管理的目标包括渐落集成开发的点对点生命周期、并允许对不同信息的协作以进行更快的执行。因此，有用的网络景观可以利用应用和集成总线/企业服务总线来反映客户景观的概括视图。而且，网络的视图可需要自动地构建并且利用实际生产系统最新地生存，以保证网络的可见度和透明度。发现网络的处理可以使用合并的和源信息模型以及信息的分析来探索系统景观， 以找到信息中的类似性和关系。由于集成技术被用作应用之间的中间物(intermediary) (并因此具有关于应用的集成终点的元数据)，所以网络的探索可以以集成技术开始。对于具有代理者(proxy)和连通性的应用，所述信息可以包括连通性和接口细节和/或操作数据。对于具有代理者、连通性、以及中介(mediation)的应用，所述信息可以包括连通性和接口细节、映射、路由、和/或操作数据。对于独立企业服务总线或集成服务器，所述信息可以包括连通性和接口细节、映射、路由、系统中心的处理、和/或操作数据。对于连接到独立企业服务总线或集成服务器的应用，所述信息可以包括连通性和/或操作数据。对于B2B网关，所述信息可以包括连通性和接口细节、映射、路由、系统中心的处理、和/或操作数据。 对于与在公司的业务伙伴处运行的B2B网关连接的应用，所述信息可以包括连通性和/或操作数据。所述信息可以被分析以确定网络景观。例如，图3是根据一些实施例的包括可以探索网络320的网络管理服务器310的系统300的框图。网络管理服务器310可以从网络 320中的各种系统接收信息。例如，网络管理服务器310可以经由超文本传输协议(“HTTP”) 通信或任何其它类型的数据交换从远程系统引入所述输入记录。例如，网络管理服务器310 和/或网络320中的系统可以与个人计算机(PC)、服务器、和/或移动设备相关联。请注意，图3表示根据一些实施例的逻辑体系结构，而实际的实施方式可以包括以其它方式安排的更多的或不同的组件。而且，这里描述的每个系统可以通过经由许多其它公共和/或专用网络通信的任何数目的设备来实现。两个或更多的设备可以位于彼此分开的位置，并且可以经由任何已知方式的网络和/或专用连接彼此通信。而且，每个设备可以包括适于提供这里描述的功能以及任何其它功能的任何数目的硬件和/或软件元件。可以结合其它实施例来使用其它拓扑。这里讨论的所有系统和处理可以实施在存储在一个或多个计算机可读介质上的程序代码中。这样的介质可以包括，例如，软盘、CD-ROM、DVD-ROM、Zip 盘、磁带、以及固态随机存取存储器(RAM)或只读存储器(ROM)存储单元。因此，实施例并不限于硬件和软件的任何特定组合。网络管理服务器310中的网络源层330可以与网络320中的系统通信，并且提供源模型存储器、源读取代理者、源写入代理者、探索和分析服务、和/或集成模型布置服务。 网络源层330可表示可经由应用系统的公共应用编程接口( “API”)和集成总线访问的元模型和操作数据。源模型可以尽可能精确地描述特定类别的系统，并且还可以是用于回写 (writing back)相应系统的数据模型。根据一些实施例，源模型只描述与业务网络管理的使用情况相关的信息的集合，而不可提供特定系统的完整模型概观。例如，它们可以经由使用为特定系统类型和系统类别开发的提取器的探索处理来创建。网络源层330还可以提供扩展点以勾住(hook in)新的源模型。对于特定的系统类型和系统类别，源模型可以要求来自被称为主数据源和辅数据源的多个数据源的信息，以提供特定系统的整体视图。对于特定系统类型和类别，探索处理可以提取主数据源，并且还可以收集辅数据源以便在适当的地方填充源模型。例如，辅数据源可以包括日志、监控数据、设计时间元数据等。对于构建网络的视图，参与所述网络的唯一物理系统的列表还可能需要被保持，并且所述系统本身和运行在它们上的软件版本形成了源模型。可以坚持源模型以允许更快的访问以及避免对系统的重复回调(call-backs)。网络管理服务器310中的网络合并层340可以包括合并器(consolidator)和 /或合并的网络模型存储器。网络合并层340可以表示网络的全局的、物理的一览视图 (one-view)。在探索之后，可以执行信息分析以找到匹配、类似性和关系，以便利用布置在彼此集成的系统上的应用和集成总线来构建网络的实际视图。例如，分析的理由可以是因为可能不被翻译为网络的自动和精确视图的源模型中的冗余和不一致性。分析的目的可以是为了识别系统之间的集成流，并由此创建整体的网络视图。例如，与网络中的特定系统通信的一组系统可以经由不同的名称和标识符来保持连接细节。分析这样的信息可以导致从网络中的其它系统到特定系统的唯一集成流的列表。合并的网络模型可以通过基于源模型分析的算法来创建。所述算法可以跨越源模型执行类似性检测和关系确定，并且依靠于基于本体论(ontology)、分类学(taxonomy)以及模式匹配和模式识别的概念的语义学。在一些情况下，对于分析处理可能需要添加附加的数据。网络管理服务器310中的网络集成模型层350可以包括丰富和集成模型组件、操作链接器、和/或仿真器和最优化器。例如，网络集成模型层350可以提供图形用户界面 (⑶I)，其可以用来访问和/或调整业务景观。再次参考网络合并层340，请注意，能够在网络上发现的被称为源模型的信息的集合可以基于应用和/或集成系统。应用的源模型可以表示客户景观中的生产企业应用，并且可以包括关于硬件系统和应用的版本的信息(例如，产品和在应用服务器上运行的软件组件)。应用还可以包含集成相关应用元数据，如代理者、接口、事件、类型、配置、和/或操作数据。对于作为集成中的参与者的企业应用，还可以发现的附加的元数据/数据包括 数据模型(业务对象和类型)；集成模型(接口、事件和类型)；通信协议(连通性)；集成要求；和/或操作数据。对于作为处理中的参与者的企业应用，可以发现的附加的元数据/ 数据包括数据模型(业务对象和类型)；参考数据(主数据、组织层级)、应用逻辑和条件 (定制表格、业务规则等)；状态转换信息(事件和活动)；工艺流程(处理模型)；和/或操作数据。用于集成的源模型可以表示集成总线系统本身(例如，在客户景观中的web方法和/或业务连接器以及关于其在集成总线上开发/配置的内容)。这可以包括关于硬件系统(包括消息传送网格)和集成管线(包括高可用性设定)数据的细节。请注意，集成总线本身可以包含各种类型的人工制品，诸如接口、事件、和类型；以及包括映射和路由的集成模型；通信协议；集成要求；操作数据，如监控日志、警报等；系统中心处理模型；和/或集成内容的版本(如产品和/或软件组件版本)。图4是根据一些实施例的业务网络管理处理400的流程图。请注意，这里描述的所有处理可以通过硬件和/或软件的任何组合来执行。所述处理可以实施在程序代码中， 所述程序代码存储在有形的介质上并且由计算机执行以提供这里描述的功能。还请注意， 这里描述的流程图并没有暗示步骤的固定的次序，并且本发明的实施例可以以可实践的任何次序来实践。在S402，发现网络景观中的多个互连的实体。例如，根据这里描述的任何实施例， 可以发现多个系统。在S404，所述实体的子集被合并到业务参与者中，其中所述合并根据至少一个基于规则的算法来执行。根据一些实施例，可以生成包括业务参与者的业务处理景观(例如，用于显示或传送)。根据一些实施例，将实体的子集合并到业务参与者中是基于一个或多个业务“事实”来执行的。如这里所使用的，术语“事实”可以指代，例如，对于合并算法可能相关的属性的重要集合。根据一些实施例，可以基于来自源的相关性质来识别事实。请注意，事实可以是机器确定的或由操作者明确规定的(例如，操作者可以被指导来提供可能基于或不基于现有或已识别性质的信息)。举例来说，事实可以表示应用的系统实例名称，并且操作者可以识别实际上指代应用的相同系统实例的、在分离的信息源中保持的不同逻辑系统实例名称。在S404执行的合并可以基于对一个或多个信息模型的认识而应用特定的规则集合。所述规则可以应用在所述事实上以创建集成网络或景观。根据一些实施例，所述规则由用于特定信息源的算法来定义和/或还可以由操作者提供。算法可以以对用于发现和合并的每个信息源的“代理”的构思来设计。所述代理可能或可能不在信息源之间共享， 并且可以方便集成网络的生成。所述算法还可以保持对原始信息源的引用，以便允许深钻 (drill-down)、验证、校正、显示和/或使用原始信息源的任何其它任务。还可以试探性地应用所述算法，以处理在集成网络中的未决引用(dangling references)，诸如对应用的传入通信(例如，没有关于谁在呼叫的知识)、从应用到网络中的外部伙伴的传出通信、和/或来自未直接链接到业务应用的物理资源的传入通信(或到所述物理资源的传出通信)。根据一些实施例，所述算法可以是容错的(fault tolerant)和/或在发现和合并步骤期间应用进行错误处理的各种语义学(例如，为了帮助处理像系统的不可用性、错误数据集或错误朋友等物理世界中的改变，和/或在用于实体的唯一标识符中的改变)。所述算法可以导致对于景观的网络模型的创建。例如，图5示出根据一些实施例的合并的网络模型500的第一级视图。在这个示例中，参与者510可以从主机520接收信息。例如，所述信息可以与经由消息流550传递的传入呼叫配置530和传出呼叫配置MO 相关联。请注意，在景观中的实际物理主机520可以与参与者510相关联，而由实际物理主机520提供的或呼叫的借口可以被找到。主机520本身可以与类别相关联，并且取决于所述类别，它还可以与应用和集成逻辑相关联。例如，图6示出根据一些实施例的另一级的合并的网络模型600。如前所述， 参与者610可以从主机620接收信息。例如，所述信息可以与经由消息流650传递的传入呼叫配置630和传出呼叫配置640相关联。根据这一级的模型600，参与者610还可以从与集成处理和/或流6M和业务应用6 相关联的系统622接收信息。对于合并，应用和 /或集成逻辑可以使用术语“系统”来统一。请注意，在图6的模型600中示出的合并级通过添加布置在主机620上的系统622来扩展模型500，所述主机620提供和/或耗费接口。根据一些实施例，用于创建合并的网络模型的算法可以在多个步骤中运行(例如，为了便于进行允许算法在源模型的大型数据集之间缩放的并行分析)。而且，所述算法可以独立于具体的源模型，并且创建网络的视图，而不管网络中的哪些主机和系统是可用的。合并器还可以协调和执行所述算法的步骤，并且将分析的实质部分委托给与源模型交互的特定探索和分析组件。图7是根据一些实施例的可以由例如图3的网络管理服务器310执行的合并处理 700的流程图。在S402，可识别景观中的唯一主机和系统。请注意，网络可以基于在客户景观上运行的物理主机。例如，物理主机可以使用不同的标识符来识别，如主机名或因特网协议(“IP”)地址。在主机上运行的逻辑实体可以被称为系统(例如，使用系统/上下文附属标识符来识别的系统)。主机和/或系统信息本身(以及关于主机和系统之间的关系的信息)可以从多个源取得并存储在不同的源模型中。这种源的示例为来自SAP 的解决方案管理器(“SMSY”) 和系统景观目录(“SLD”)、来自Hewlett- Packard (惠普)的Open View(开放视图)、 来自 IBM 的 Tivoli、来自 Computer Associates 的 Unicenter、以及来自Microsoft (微软)的系统管理服务器(“SMS”)。例如，对于远程管理，物理主机可以用系统管理软件来注册。在一些情况下，系统管理软件可以提供API以经由适配器读取和写入主机和系统信息，并且源读取代理可能能够取得主机和系统信息并将其存储为源模型。主机和系统可以以不同的方式表示在各种源模型中，并且作为结果，可以在合并的网络模型中创建唯一主机和系统的列表。请注意，可能没有用于主机或系统的单一的通用的可用识别方案，并且没有随时间稳定的标识符(例如，随着时间，不同的IP地址可以用于一个DNS主机名，而不同的主机名可以用于同一 IP地址)。因此，实施例可以使用所有可能标识符的集合内的等同类来识别主机和系统。每个等同类的元素可以包括已知识别同一主机或系统的所有标识符。例如，可能存在用IP地址“10. 66. 145. 51”、DNS名称“vml2171. wdf. sap. corp”、以及SAP名称“BXI”识别的主机。然后，识别这个主机的等同类可以包含所有三个标识符，并且对这三个标识符之一的任何引用可以识别特定的主机。虽然等同类可能在时间上不稳定，但是有可能当等同类中的另一个元素改变时至少一个元素不改变。 以这种方式，在存在持续的、但是逐步的改变的情况下，可以在相当长的时间段内保持本体 (identity)。请注意，源模型可以被取得并保存在网络源层内，允许在源模型中的特定实例的唯一识别。将源模型的副本保存在网络源层中还可以允许对那些源模型的有效查询，以搜索对主机和/或系统标识符的引用。为了确定所发现的特定信息的出处(lineage)，所发现的信息可以用标识符来标注，该标识符指的是包含原始信息的源模型。添加新发现的信息和去除过时信息的处理可以是连续的。为了能够确定哪个信息是相关的(以及哪个信息是不再相关的)，所发现的每条信息可以用时戳来标注。当由于信息在更低的层上而从模型中去除信息时(例如，源或合并的模型)，可以考虑该信息是否在更高的层上仍然被参考(例如，合并的模型)。例如，如果确定主机或系统不再存在，则可能仍然需要保持(并且被标记为不可用的)直到不再被参考为止。为了形式化合并算法，可以实现基于规则的方式。在这个方式中，所发现的信息可以通过事实的集合来描述，并且合并算法可以描述为规则的集合。例如，所述规则可以从最终导向合并的网络模型的所发现事实中导出新的事实。为了识别唯一主机和系统，网络发现可以提供对于以下属性的事实(所有通过发现提供的属性都有后缀“_disc”)"host_disc(hostId, URI) ”可以将主机 Id(hostld)(例如，IP 地址)与标识符相关，所述标识符可以指的是包含关于这个主机的信息的源模型。根据一些实施例，机器的同源簇(homogenous clusters)还被考虑为一个主机。请注意，来自所发现的不同系统的源模型可以使用不同的主机Id(例如，另一个IP地址或DNS名称)，并且提供关于相同物理主机的不同信息。“same_host_disc(hostIdl，hostId2)”可以连接指的是相同物理主机的两个主机 Id(例如，IP地址和DNS名称)。"system_disc(systemId,URI) ”可以将系统Id与标识符相关，如统一资源标识符 (“URI”)，该标识符指的是包含关于系统的信息的源模型。如这里所使用的，“系统”可以指的是逻辑实体，该逻辑实体可以是例如应用或集成系统/流。对于主机，来自所发现的不同系统的源模型可以使用不同的系统Id，并且提供关于同一系统的不同信息。“same_system_disc (systemldl, systemld2) ” 可以连接指的是同一系统的两个系统Id。"runs_on_disc(systemId, hostld)，，可以将系统连接到其运行的主机。请注意， 根据一些实施例，在一个主机上可以运行多于一个系统，但是一个系统不能运行在多于一个主机上。在S704，可以基于源模型确定到系统的传入呼叫和来自系统的传出呼叫。请注意， 基于源模型，可能识别主机和系统标识符，并且还可能查询和识别传入呼叫配置和/或传出呼叫配置。对于许多到系统的传入呼叫，可以提供传入呼叫配置(例如，诸如发送者信道或web服务端点配置)。对于来自系统的每个传出呼叫，可能需要保持传出呼叫配置，以启动到所呼叫的系统的消息流(例如，接收者信道、web服务目的地、以及web服务逻辑端口配置)。在一些情况下，除了被远程使能的功能之外，可能没有所要求的传入呼叫配置。在这种情形下，在从那个特定系统中检索的源模型中可能不会检测到配置。根据一些实施例，S704的执行可以导致用于特定系统Id的传出和传入呼叫图，诸如图8中所示的图形800。在这个示例中，Sl是与从其它系统820接收传入呼叫并向其它系统830提供传出呼叫的“系统id”相关联的系统810。对于传入和传出呼叫配置，网络源层可以提供以下事实“ incoming_disc (systemld, URI) ”可以将系统 Id 与 URI 相关，该 URI 能够用来检索关于所识别的系统的传入配置的详细信息。"outgoing_disc (systemld, URI) ”可以将系统 Id 与 URI 相关，该 URI 能够用来检索关于所识别的系统的传出配置的详细信息(类似于incoming—disc)。再次参考图7，在S706，可以基于传出呼叫确定来自系统的消息流。也就是说，传出呼叫可以对特定系统进行，并且相应呼叫配置可以包含用于接收主机或系统的标识符。如果可用，则这些标识符可以与在S702确定的标识符进行匹配。否则(当没有标识符可用时)，则在S708，可以替代地使用这些呼叫配置。作为S706的结果，可以生成呼叫图，诸如在图9中示出的图形900(例如，通过添加向其传递传出呼叫的系统来扩展系统的呼叫图)。 也就是说，已经基于传出呼叫配置信息扩展了图8的图形800 (如图9中的虚线箭头所示)， 以包括系统S2到S5。为了将传出呼叫配置与接收者相关，网络源层可以提供以下事实"receiver_disc (URLsystemId) ”可以将用于传出配置的URI与系统Id相关，该系统Id识别接收系统(并且系统Id可以从给定配置中提取)。"receiver_host_disc (URI，hostld) ”可以将用于传出配置的 URI 与主机 Id(hostld)相关，该主机Id识别接收主机。这可以类似于reCeiver_disC。但是，当一些传出配置(例如，用于web服务)仅仅指定接收主机时，接收系统可能不总被直接确定。在呼叫系统和被呼叫系统之间的通信可以被称为“消息流”。如果传出呼叫配置包含用于接收者的标识符，则可能存在相应的outgoing_diSC和reCeiver_disC事实，它们全都指向识别这个传出呼叫配置的URI。因此，通过将这些事实加入(join)到URI上，可以确定消息流。"message_f low (systemldsender, systemldReceiver)，， 禾口 "message_flow_ host(hostIdSender，hostIdReceiver)，，可以确定在系统和主机之间的消息流。例如，可以使用呼叫配置的URI来确定在系统之间的消息流。在S708，可以基于传入呼叫来确定到系统的消息流。请注意，传入呼叫配置有时也可以识别特定的发送主机或系统。如果可用，这样的标识符可以与在S702确定的标识符进行匹配。虽然在传出配置中找到接收者可能是常见的，但是在传入配置中指定特定发送者则不那么常见。因此，可能希望将发现比传入/发送者对更多的传出/接收者对。如图10 的图形1000所示，S708可以通过添加从其接收到传入呼叫的系统、来扩展系统的呼叫图。 也就是说，基于传入呼叫配置信息，图形1000已经被扩展(如图10的虚线箭头所示)以现在包括系统S4和S5。为了将传入呼叫配置与发送者相关，网络源层可以提供以下事实"sender_disc (URLsystemId) ”可以将用于传入配置的URI与识别发送系统的系统Id相关。类似于S706，如果传入呼叫配置包含用于发送者的标识符，则可能存在相应的 incoming_disc和sender_disc事实，它们二者指向识别这个传入呼叫配置的URI。因此， 消息流可以通过将这些事实加入到URI上来确定在S710，用于系统的呼叫图可以被融合以形成网络。请注意，S702到S708识别唯一主机和系统并确定消息流，该消息流能够从在所发现的单一系统上可用的信息中导出。 为了确定在主机和系统之间的消息流，可以匹配来自所发现的不同系统的已经识别的传入和传出呼叫配置。例如，这可以通过匹配兼容协议、匹配兼容消息类型等来进行。在一些情况下，传入呼叫配置可能不与已经识别的传出呼叫配置匹配(例如，web 服务端点被配置在应用系统上，但是在景观中的任何系统上并没有相应的web服务目的地，或者数据库适配器可以被配置在集成总线上，用于从数据库读取数据，但是没有关于其中为了这个读取操作安装数据库本身的系统的特定配置)。还可能存在确定没有用于其的相应传入呼叫配置的现有传出呼叫配置(例如，到系统的目的地不具有相应的传入呼叫配置)。根据一些实施例，这样的配置可能保留在合并的模型中。在确定新的消息流之后，可以在图形之间创建新的链接。新的链接和保持的“未链接的”配置可以导致诸如图11中所示的整个业务处理景观的图形1100之类的图形。在S712，消息流可以与应用和集成内容相链接。与主机和系统的传出和传入呼叫配置可以导致网络的视图。然而这些消息流可能只包括在主机和系统之间的通信。传出和传入呼叫配置还可以具有到被布置和运行在系统上的应用和集成内容的链接。因此，S712 可以确定在主机和系统内的这个链接。系统的类别可以确定源模型，并因此可以定义能够确定的链接。例如，在应用主机和系统的情况下，S712可以为特定传出或传入呼叫配置确定到特定应用代理者、以及经由代理者到应用本身的链接。请注意，这个确定可以是有帮助的， 因为特定主机可能具有同时运行的多个引用。而且，取决于应用的固有结构，可能存在触发传出呼叫的处理步骤，而其它步骤接收传入呼叫(如果可能，这可以基于应用源模型和诸如日志和/或痕迹的操作数据来分析)。在集成总线/企业服务总线/B2B网关的情况下，S712可以对于特定传入呼叫配置确定到特定传出呼叫配置或传出呼叫配置集合的链接。例如，当接收消息时，这可以翻译为在集成总线上布置、配置和执行的集成处理或集成流。再次，取决于集成内容源模型和例如日志和痕迹的操作数据，可能通过集成总线跟踪消息的路径。例如，这个分析可以链接传入呼叫与传出呼叫，并尽可能多地确定这之间的细节。因此，实施例可以提供有效和自动的网络景观，该景观对于IT管理者和业务参与者二者都是有用的。这里已经为了例示的目的单独描述实施例。本领域技术人员从这个描述中将认识至IJ实施例并不限于所描述的那些实施例，并且可以用仅由所附权利要求的精神和范围限定的修改和替换来实践。
权利要求
1.一种计算机实现的方法，包括 在网络景观中发现多个互连的实体；将所述实体的子集自动地合并到业务参与者中，其中所述合并根据至少一个基于规则的算法来执行；以及生成包括所述业务参与者的业务处理景观。
2.如权利要求1所述的方法，其中，所述实体中的至少一些与以下各项中的至少一个相关联(i)业务应用、( )业务系统、(iii)文件系统、(iv)数据库管理系统、或(ν)企业资源计划系统。
3.如权利要求1所述的方法，其中，所述发现步骤包括分析传入呼叫配置信息和传出呼叫配置信息。
4.如权利要求3所述的方法，其中，所述发现步骤至少部分地基于从操作者接收的信肩、ο
5.如权利要求1所述的方法，其中，所述合并步骤至少部分地基于匹配、类似性、或关系分析。
6.如权利要求5所述的方法，其中，所述合并步骤至少部分地基于从操作者接收的信肩、ο
7.如权利要求1所述的方法，其中，所述算法包括试探性的算法。
8.如权利要求1所述的方法，其中，所述算法至少部分地基于(i)应用系统概观、(ii) 产品版本、(iii)连通性信息、(iv)在中间件系统或应用系统上运行的集成、(ν)接口、(vi) 集成处理模型、(vii)操作数据、(viii)业务处理描述、(ix)业务角色和参与者、(χ)业务对话、或(xi)业务协作。
9.如权利要求1所述的方法，其中，所述发现步骤和所述合并步骤被基本上实时地执行。
10.如权利要求1所述的方法，其中，所述发现步骤和所述合并步骤包括基本上连续的处理。
11.如权利要求1所述的方法，其中，所述发现步骤和所述合并步骤中的至少一个基于表示经由应用编程接口能访问的元模型和操作数据的源模型。
12.如权利要求11所述的方法，其中，所述应用编程接口与以下各项中的至少一个相关联(i)应用系统、或(ii)集成总线。
13.一种存储程序代码的非暂时计算机可读介质，所述程序代码可由计算机执行以执行一种方法，所述方法包括在互连的系统的景观中识别多个唯一主机和系统； 基于源模型确定到每个系统的传入呼叫和来自每个系统的传出呼叫； 基于传出呼叫确定来自每个系统的消息流； 基于传入呼叫确定到每个系统的消息流；融合用于所述系统的呼叫图以创建所述景观的业务处理网络；以及链接用于所述业务处理网络的消息流、应用内容、以及集成内容。
14.如权利要求13所述的介质，其中，所述识别步骤与源模型相关联。
15.如权利要求13所述的介质，其中，所述传入呼叫的确定至少部分地基于传入呼叫配直信息。
16.一种网络管理服务器，包括网络服务层平台，用于在网络景观中发现多个互连的实体；以及网络合并层平台，用于将所述实体的子集自动地合并到业务参与者中，其中所述合并步骤根据至少一个基于规则的算法来执行。
17.如权利要求16所述的网络管理服务器，其中，网络源层平台还包括以下各项中的至少一个(i)探索和分析服务、(ii)集成模型布置服务、(iii)源读取代理、(iv)源写入代理、或(ν)源模型。
18.如权利要求16所述的网络管理服务器，其中，所述网络合并层平台还包括以下各项中的至少一个(i)合并的网络模型或(ii)合并器。
19.如权利要求16所述的网络管理服务器，还包括网络集成模型层平台，用于提供图形用户界面，该图形用户界面显示包括业务参与者的业务处理景观。
20.如权利要求19所述的网络管理服务器，其中，所述网络集成模型层平台还包括以下各项中的至少一个(i)操作链接器、( )仿真器和优化器、或(iii)丰富和集成模型组件。
全文摘要
根据一些实施例，可以在网络景观中发现多个互连的实体。然后所述实体的子集可以被自动地合并到业务参与者中，所述合并可以根据至少一个基于规则的算法来执行。然后，包括业务参与者的业务处理景观可以被生成和/或显示给操作者。
文档编号H04L12/24GK102468981SQ20111035679
公开日2012年5月23日 申请日期2011年11月11日 优先权日2010年11月11日
发明者A.巴特, D.里特, J.丹纳, T.维斯特曼 申请人:Sap股份公司