專利名稱：使用消息擴展crm功能的制作方法
使用消息擴展CRM功能祖且 冃豕典型的商業(yè)應用程序可以具有多個商業(yè)實體，并且能夠基于商業(yè)邏輯對這些 實體執(zhí)行各種操作。這種應用程序提供允許訪問并執(zhí)行那些實體相關商業(yè)邏輯的應 用程序編程接口 (API)。由于互操作性是商業(yè)應用程序中的關鍵要求，可以使用 Web服務技術來設計API。 API的消費者依賴于API的簽名，并且在API的生存 期期間對API作出改變時受到影響。同樣與這種應用程序中存在的商業(yè)實體的數 目成比例，通過API來定義類似數目的靜態(tài)操作(方法)并使其可用。概述公開了在CRM程序中擴展API功能的方法以及實現(xiàn)該方法的系統(tǒng)。該方法可 允許用戶使用請求和響應消息來與CRMweb服務模塊通信，以通過擴展先前定義 的類和通過單個API接口來創(chuàng)建新的商業(yè)邏輯和操作。通過基于由分類支持的商 業(yè)操作將商業(yè)實體分類來創(chuàng)建目標基類，其中可以審閱目標類分層結構來確定哪些 商業(yè)實體支持哪些操作。附1是可依照權利要求操作的計算系統(tǒng)的框圖；圖2是允許商業(yè)應用程序的用戶經由消息執(zhí)行商業(yè)邏輯和訪問商業(yè)操作及數 據的面向消息的API的圖示；圖3是消息中心方法的概念視圖的圖示；圖4是示出與Execute方法結合使用的請求和響應消息的類分層結構的類圖； 圖5示出在CRM系統(tǒng)中使用消息來擴展應用程序編程接口的功能的方法；以及圖6示出兩個示例的Target (目標)類分層結構。描述盡管下列文本闡明了許多不同實施例的詳細描述，但是應該理解，該描述的 法律范圍由本專利所附的權利要求書的文字所定義。該詳細描述應被解釋為僅是示 例性的，而不描述所有可能的實施例，因為描述所有可能的實施例是即使不是不可 能的也是不現(xiàn)實的。使用當前的技術或在本專利申請日之后開發(fā)的技術，可以實現(xiàn)
許多替代實施例，這仍然會落在權利要求書的范圍之內。也應該理解，在本專利中，除非使用句子"如此處所用，術語<_'特此被定義為意指……"或者類似句子來明確地定義一個術語，否則不管是明確地還是 含蓄地，沒有限制該術語意義超出其平?；蚱胀ㄒ饬x的意圖，并且，這一術語不應 該被解釋為被限制在基于本專利的任何部分中(除了權利要求書的語言之外)所做 的任何陳述的范圍中。在本專利中以符合單一意義的方式提及在本專利所附的權利 要求書中所陳述的任何術語，在這樣的范圍內，這樣做僅僅是為了清晰起見以便不 使讀者混淆，并且，這樣的權利要求術語不旨在含蓄地或以其他方式地被限制于該單一意義。最后，除非通過陳述詞語"意指"和功能而沒有敘述任何結構來定義一個權利要求要素，否則任何權利要求要素的范圍不旨在基于35U.S.C. § 112申請書的第六段來解釋。

圖1例示了合適的計算系統(tǒng)環(huán)境100的例子，在該計算系統(tǒng)環(huán)境上可以實現(xiàn) 用于所要求的方法步驟和裝置的逐步驟的系統(tǒng)。計算系統(tǒng)環(huán)境100只是合適的計算 環(huán)境的一個例子，它并不意味著對權利要求書的裝置或方法的使用范圍和功能提出 任何限制。計算機環(huán)境100也不應該被解釋為具有與在示例性操作環(huán)境100中所例 示的任一組件或它們的組合有關的任何依賴或要求。所要求的方法步驟和裝置能夠用多個其他通用或專用計算系統(tǒng)環(huán)境或配置操 作。適用于使用權利要求書的方法或裝置的眾所周知的計算系統(tǒng)、環(huán)境、和/或配 置的例子包含但不限于個人計算機、服務器計算機、手持式或膝上型設備、多處 理器系統(tǒng)、基于微處理器的系統(tǒng)、機頂盒、可編程的消費性電子產品、網絡PC、 小型計算機、大型計算機以及包括任何以上系統(tǒng)或設備的分布式計算環(huán)境，等等。所要求的方法步驟和裝置可以用諸如程序模塊的由計算機執(zhí)行的計算機可執(zhí) 行指令的通用上下文描述。通常，程序模塊包括執(zhí)行特定的任務或實現(xiàn)特定的抽象 數據類型的例程、程序、對象、組件和數據結構等等。也可以在分布式計算環(huán)境中 實踐諸方法和裝置，在分布式計算環(huán)境中，由通過通信網絡鏈接的遠程處理設備執(zhí) 行任務。在分布式計算環(huán)境中，程序模塊可以位于包括存儲器存儲設備在內的本地 和遠程計算機存儲介質中。參見圖1，用于實現(xiàn)所要求的方法步驟和裝置的示例性系統(tǒng)包括一個計算機 110形式的通用計算設備。計算機110的組件包括但不限于處理單元120、系統(tǒng) 存儲器130、將包括系統(tǒng)存儲器在內的各個系統(tǒng)組件耦合到處理單元120的系統(tǒng)總 線121。系統(tǒng)總線121可以是包括使用多種總線體系結構中的任一種的存儲器總線
或存儲器控制器、外圍總線以及局域總線在內的若干總線結構類型中的任一種。作 為例子而非限制，這樣結構包括工業(yè)標準體系結構(ISA)總線，微通道體系結構(MCA)總線，增強ISA (EISA)總線，視頻電子標準協(xié)會(VESA)局部總線和 也被稱為附夾板(Mezzanine)總線的外圍部件互連(PCI)總線。計算機110通常包括多種計算機可讀介質。計算機可讀介質可以是能由計算 機110訪問的任何可用介質，而且包含易失性和非易失性介質以及可移動和不可移 動介質。作為例子而非限制，計算機可讀介質可以包括計算機存儲介質和通信介質。 計算機存儲介質包括易失性和非易失性、可移動的和不可移動的介質，這些介質用 存儲信息如計算機可讀指令、數據結構、程序模塊或其他數據等信息的任何方法或 技術實現(xiàn)。計算機存儲介質包括但不局限于RAM、 ROM、 EEPROM、閃存或者 其他存儲器技術、CD-ROM、數字通用盤(DVD)或其他光盤存儲、磁帶盒、磁 帶、磁盤存儲或者其他磁存儲設備、或者任何其他可以用于存儲所需信息并可由計 算機110訪問的介質。通信介質一般具體化為如載波或者其他傳輸機制等的已調制 的數據信號中的計算機可讀指令、數據結構、程序模塊或其他數據，并包括任何信 息傳遞介質。術語"已調制的數據信號"是指以在該信號中編碼信息的方式來設置 或改變其一個或多個特性的信號。作為例子而非限制，通信介質包括有線介質如有線網絡或者直接線連接，以及無線介質如聲學、射頻、紅外和其他無線介質。以上 任何一個的組合也應當被包括在計算機可讀介質的范圍之內。系統(tǒng)存儲器130包括易失性和/或非易失性存儲器如只讀存儲器(ROM) 131 和隨機存取存儲器(RAM) 132形式的計算機存儲介質?；据斎?輸出系統(tǒng)133 (BIOS)通常被存儲在ROM 131中，該基本輸入/輸出系統(tǒng)包含幫助在計算機110 內的各個元件之間例如在啟動過程中傳輸信息的基本例程。RAM 132通常包含處 理單元120可立即訪問和/或目前正在操作的數據和/或程序模塊。作為例子而非限 制，圖1例示了操作系統(tǒng)134、應用程序135、其他程序模塊136以及程序數據137。計算機110也可以包括其他可移動/不可移動、易失性/非易失性的計算機存儲 介質。僅僅作為例子，圖1例示了從不可移動的非易失性磁介質讀取或向其中寫入 的硬盤驅動器140、從可移動的非易失性磁盤152讀取或向其中寫入的磁盤驅動器 151、以及從可移動的非易失性光盤156 (例如，CDROM或其他光學介質)讀取 或向其中寫入的光盤驅動器155?？梢栽谠撌纠圆僮鳝h(huán)境中使用的其他可移動/ 不可移動、易失性/非易失性計算機存儲介質包括但不限于，磁帶盒、閃存卡、數 字通用盤、數字錄像帶、固態(tài)RAM、固態(tài)ROM等等。硬盤驅動器141通常通過
不可移動存儲器接口如接口 140連接到系統(tǒng)總線121，而磁盤驅動器151和光盤驅 動器155通常通過可移動存儲器接口如接口 150連接到系統(tǒng)總線121。
上面討論的并且在圖1中所示的驅動器及其相關的計算機存儲介質，為計算 機110提供計算機可讀指令、數據結構、程序模塊和其它數據的存儲。例如，在圖 1中，硬盤驅動器141被例示為存儲操作系統(tǒng)144、應用程序145、其它程序模塊 146和程序數據147。注意，這些組件可以等同于或不同于操作系統(tǒng)134、應用程 序135、其他程序模塊136和程序數據137。這里對操作系統(tǒng)144、應用程序145、 其他程序模塊146和程序數據147給予不同的標號，以說明至少它們是不同的拷貝。 用戶可以通過輸入設備如鍵盤162和定位設備161(通常指鼠標、跟蹤球或觸摸板) 向計算機20輸入命令和信息。其他輸入設備(未示出)可以包括麥克風、操縱桿、 游戲手柄、圓盤式衛(wèi)星天線、掃描儀等等。這些和其他輸入設備往往通過被耦合到 系統(tǒng)總線的用戶輸入接口 160連接到處理單元120，但也可以通過其他接口和總線 結構如并行端口、游戲端口或通用串行總線(USB)連接。監(jiān)視器191或其他類型 的顯示設備也通過接口如視頻接口 190連接到系統(tǒng)總線121。除監(jiān)視器外，計算機 還可包括其它外圍輸出設備如揚聲器197和打印機196，它們可通過輸出外圍接口 195連接。
計算機110可以運行在使用到一臺或多臺遠程計算機如遠程計算機180的邏 輯連接的網絡化環(huán)境中。雖然在圖1中僅僅示出了存儲器存儲設備181，但是遠程 計算機180可以是個人計算機、服務器、路由器、網絡PC、對等設備或其他公共 網絡節(jié)點，并通常包括上文所述與計算機IIO相關的許多或所有元件。圖1所描述 的邏輯連接包括局域網(LAN) 171以及廣域網(WAN) 173，但是也可以包括其 他網絡。這類網絡環(huán)境常見于辦公室、企業(yè)范圍內的計算機網絡、內聯(lián)網和因特網。
當用于LAN網絡環(huán)境時，計算機110通過網絡接口或適配器170連接到LAN 171。當用于WAN網絡環(huán)境中，計算機110通常包括調制解調器172或用于在 WAN 173 (例如，因特網)上建立通信的其他裝置。可以內置或者外置的調制解 調器172可以通過用戶輸入接口 160或其他適當的機制連接到系統(tǒng)總線121。在網 絡化環(huán)境中，相對于計算機110描述的程序模塊或它們的部分可以被存儲在遠程存 儲器存儲設備中。作為例子而非限制，圖1將遠程應用程序185例示為駐留在存儲 設備181上。應該明白，所示網絡連接是示例性的，并且可以使用在計算機之間建 立通信鏈路的其他方式。
典型的商業(yè)應用程序可以具有多個商業(yè)實體，并且能夠基于商業(yè)邏輯對這些
實體執(zhí)行各種操作。這種應用程序提供允許訪問并執(zhí)行與那些實體有關的商業(yè)邏輯 的應用程序編程接口 (API) 。 API可以是開發(fā)者用于與硬件設備、網絡、操作系 統(tǒng)、軟件庫或應用程序交互的一組程序、代碼庫、或接口。由于互操作性是商業(yè)應
用程序中的關鍵要求，可以使用Web服務技術來設計API。 API的消費者依賴于 API的簽名，并且在API的生存期期間對其作出改變時受到影響。同樣與這種應用 程序中存在的商業(yè)實體的數目成比例，通過API來定義類似數目的靜態(tài)操作(方 法)并使其可用。這種模型由于若干個原因而難以擴展
1. 對API任何改變要求對其所有消費者的改變?；诜椒ǖ臄U展性不是非常 通用的且成本效率較低。為了擴展這種API，需要將新的方法添加到API組；
2. 對于API支持的那種類型系統(tǒng)的任何改變要求對API實現(xiàn)和所有消費者的 改變；
3. 管理及維護大量方法的持續(xù)的復雜性和成本；
4. 管理不同類型的商業(yè)實體間操作和數據的一致性的持續(xù)成本和復雜性；
5. 在多個不同版本的應用程序中的API的壽命及其生存期；
6. 由于API中的大量消息和/或類型，編程模型和開發(fā)體驗會是復雜的；
7. 通常最終用戶引入的定制和新的類型(例如新的商業(yè)實體)相對于系統(tǒng)商 業(yè)實體要求不同的編程模型；
8. API的最終用戶不能方便地擴展API的功能；以及
9. 工作流和商業(yè)過程不能方便地與API集成。
面向消息的方法創(chuàng)建了可擴展點，所述可擴展點解決了所述的所有問題，并 提供允許通過新的消息來實現(xiàn)新的商業(yè)邏輯的架構。這種方法接受任何消息，甚至 是實現(xiàn)之后定義的消息，而無需修改API簽名或類型系統(tǒng)。面向消息的方法具有 以下優(yōu)點
1. 對API的任何改變可以通過添加新的消息來實現(xiàn)，而無需改變方法的簽名 或影響方法的現(xiàn)有消費者；
2. 可以擴展系統(tǒng)類型，而無需打斷現(xiàn)有的消費者；
3. 在開發(fā)環(huán)境中，相對大量的商業(yè)實體和商業(yè)邏輯可以被合并在較好地組織、 能夠瀏覽的消息列表中，作為改進可用性和開發(fā)體驗的方法；
4. 可經由簡單的消息類分層結構顯著地降低管理不同類型的商業(yè)實體間操作 和數據的一致性的持續(xù)成本和復雜性；
5. 由于單個可擴展點消息，來改進API的壽命及其生存期；
6. 由最終用戶引入的定制和新的類型(例如新的商業(yè)實體)可以適合消息類 分層結構，并且可以使用相對于消息商業(yè)實體相同的編程模型來消費；
7. 通過定義新的消息可方便地擴展API及其功能；以及
8. 通過一組新定義的、包括工作流方法和過程描述的消息，可以方便地將工 作流和商業(yè)過程與API集成。
面向消息的API可以允許商業(yè)應用程序的用戶經由消息來執(zhí)行商業(yè)邏輯并訪 問商業(yè)操作和數據。圖2可以是例如在顧客關系管理(CRM)系統(tǒng)中這種系統(tǒng)的 設計的圖示。CRM可以是維護具有組織和維護與客戶機、顧客和服務代理之間有 關商業(yè)關系和顧客滿意度的關系的能力的方法，而CRM應用程序是顧客關系管理 應用程序的首字母縮寫，是概述和跟蹤顧客以協(xié)助銷售人員為該顧客提供更好的服 務，以獲得總體改進的顧客關系的程序。
CRM web服務200可以是商業(yè)應用程序的用戶使用的接口 。接口揭示出定制
之后添加到CRM系統(tǒng)中的新消息(擴展)以及通過相同的接口初始就被包括在系
統(tǒng)中的原始消息。用于系統(tǒng)原始商業(yè)實體的同一接口和編程模型被用于定制商業(yè)實
體，以提供無縫的編程體驗。該web服務200具有由web服務定義語言(WSDL)
提供的良好定義的web服務描述，并且可以用任何其他期望的定義語言來定義。
WSDL可以是基于XML的契約語言，用于描述Web服務供應商經由UDDI提供
的網絡服務。UDDI代表統(tǒng)一描述、發(fā)現(xiàn)和集成，并且可以是基于XML和SOAP
的査找服務，以供Web服務消費者定位網絡上可用的Web服務和可編程資源。
WSDL可以使用其公共方法、所有參數的數據類型、返回值以及綁定來向Web服
務消費者描述Web服務。SOAP代表簡單對象訪問協(xié)議，它可以是輕量的、基于
XML的協(xié)議，用于在通過網絡發(fā)送Web服務請求和響應消息之前對其中的信息進
行編碼。SOAP消息可以獨立于任何操作系統(tǒng)或協(xié)議，并且可以使用包括SMTP、
MIME和HTTP的多種因特網協(xié)議來傳送。為系統(tǒng)的用戶動態(tài)地生成WSDL，并
且使得他們可以訪問web服務并對其編程。
系統(tǒng)可以具有單個web服務方法，稱為Execute (執(zhí)行)。示例可以如下 [WebMethod] public Response Execute (Request request)
可以使用相同的方法和接口來與用于系統(tǒng)中的各種商業(yè)實體和商業(yè)操作和數 據。Execute方法可以采用請求消息210并返回響應消息220。請求消息可以由CRM web服務230的客戶機來實例化和構建。調用者可以通過調用web服務230上的
Execute方法將消息發(fā)送給CRM平臺?？蛻魴C240可以在將消息發(fā)送給CRM web 服務200之前將其串行成SOAP分組，并接著在CRM web平臺上將其反串行成消 息對象。接著可以將消息發(fā)送給服務器250并在那里進行處理。消息處理的結果可 以經由響應消息220被返回給Execute web方法的調用者。請求和響應消息內容都 可以是強類型的，以便當調用者使用各類型時，允許調用者使用更好的開發(fā)環(huán)境支 持。也應該注意SOAP是在分散、分布式環(huán)境中用于交換結構化信息的可用協(xié)議 之一，但是可以使用任何適當的協(xié)議。
圖3是示出與Execute方法結合使用的請求和響應消息的類分層結構的類圖 示。可以從請求消息導出若干個類，以表示由CRM系統(tǒng)支持的不同的商業(yè)操作。 每個請求導出類具有相應的響應導出類。例如CreateRequest (創(chuàng)建請求)類是從 請求類導出的，并對應于從響應類導出的CreateResponse (創(chuàng)建響應)類。作為一 般規(guī)則，關于典型web方法的參數可以被映射到請求消息310的成員，并且典型 web方法的返回參數可被映射到響應消息320的成員。所有支持的商業(yè)操作和商業(yè) 邏輯都可以經由請求消息330的子類來揭示，并且以請求和響應關鍵字為后綴。消 息可以都以操作名稱開始，其中操作是CRM平臺中支持的商業(yè)操作。這些命名約 定都允許在開發(fā)環(huán)境中方便地瀏覽消息并改進了 API可用性。
圖4可以示出使用消息來擴展CRM系統(tǒng)中應用程序編程接口的功能的方法。 在框405處，方法可以選擇一操作，其中該操作是CRM操作。由于面向消息的設 計是以過程為中心的，因此編程體驗可以由開發(fā)者通過選擇具體的請求消息來選擇 所需的商業(yè)操作(創(chuàng)建帳戶、合并帳戶、發(fā)送電子郵件)開始。
在框405處，該方法可以基于所選操作傳遞請求消息。傳遞可以在任何有線 或無線信道上使用適用于所選信道的通信協(xié)議來進行。如上所述，方法可以采用請 求消息并返回響應消息。請求消息可以由CRM網絡服務的客戶機來實例化和構建。 調用者可以通過調用web服務上的Execute方法將消息發(fā)送給CRM平臺。消息可 以經由諸如SOAP的任何傳輸協(xié)議來發(fā)送給CRM服務器并在該處獲得處理。
在框415處，如果請求消息具有商業(yè)實體類型名稱作為請求消息的部分，那 么這會向用戶指示消息僅對于該特定的商業(yè)實體有效，然后該用戶可以實例化請求 消息；在框420處填充請求消息參數；并且接著在框425處將請求消息發(fā)送給CRM 服務器以供處理。
在框430處，如果請求消息是通用請求消息，在請求消息名稱中沒有任何商 業(yè)類型名稱，那么一用戶會實例化請求消息。在框435處，用戶會通過査看目標類
類型并實例化目標基類來發(fā)現(xiàn)所支持的目標商業(yè)實體。在框440處，用戶會用目標 類參數來填充請求消息。該方法確保用戶在設計時間僅對給定的商業(yè)實體執(zhí)行支持 的操作。
在框445處，方法會將目標類添加到請求消息，并且在框425處，方法會執(zhí) 行請求消息。執(zhí)行的結果會經由響應消息被返回給Execute web方法的調用者。請 求和響應消息內容都是強類型的，以便當用于各類型時，允許調用者使用更好的開 發(fā)環(huán)境支持。當然，這僅是執(zhí)行該方法的一種方式，其他方式也是可能的。
在框450處，用戶會實例化在請求消息名稱和請求消息類中均不引用任何商 業(yè)實體的請求消息。這種類型的消息是商業(yè)實體不可知論的，并且可以用于執(zhí)行無 需對商業(yè)實體的任何引用的一般操作。在框455處，方法可以填充請求消息參數， 并且接著請求消息會被發(fā)送給CRM服務器以便在框425處處理。
可以經由新的消息來擴展API。由于所有的新的消息是從基本請求和響應消息 導出的，所以添加新的消息不會要求對方法簽名的改變。例如，CRM的一個版本 可以具有通過揭示SendEmailRequest(發(fā)送電子郵件請求)消息來發(fā)送電子郵件的能 力，并且稍后可以通過方便地添加被稱為SendFaxRequest (發(fā)送傳真請求)的新的 消息來添加通過電話線發(fā)送傳真的新功能。由于這兩種消息都是從基本請求類導出 的，因此無需對Execute方法的改變。同樣，類分層結構的存在也允許消息的串行 和反串行以適當地在客戶機和服務器上發(fā)生。
請求消息分層結構的多態(tài)性可以意味著，相同的接口可以用于多個商業(yè)實體 類型，而無需為每個商業(yè)實體創(chuàng)建新且單獨的接口。例如CreateRequest可以用于 經由相同的消息和相同的Execute方法創(chuàng)建不同類型的商業(yè)實體的新的實例。這是 面向消息方法的優(yōu)點之一。
可以在系統(tǒng)中定義不同類型的消息以滿足在商業(yè)應用程序中提供的不同類型 的商業(yè)操作。 一些消息表示通用操作，并適用于系統(tǒng)中的大多數商業(yè)實體，而一些 其他的消息更針對特定的一組商業(yè)實體。使用商業(yè)應用程序API的開發(fā)者會需要 發(fā)現(xiàn)在設計環(huán)境中在哪些商業(yè)操作上哪些商業(yè)實體被支持，并無需參考文檔?？山?由Target類和商業(yè)實體分類來解決所公開的系統(tǒng)。Target類可以使開發(fā)者能夠標識 為哪些商業(yè)實體支持哪些消息。可以基于分類所支持的商業(yè)操作將商業(yè)實體分組到 不同的分類下，并且為每個分組創(chuàng)建Target基類。
圖5示出兩個示例的Target類分層結構。TargetMerge (目標合并)510和 TargetQuantify (目標量化)520各自表示支持多種操作的商業(yè)實體分類。屬于該 類的每個商業(yè)實體具有從這些類中導出的Target類。例如在TargetMerge情況下，TargetMergeAccount (目標合并帳戶)類是導出類，示出Account商業(yè)實體是TargetMerge分類的成員。有了這個類分層結構，就使得API的用戶能夠編程上地或通過使用他們的開發(fā)環(huán)境中的工具來瀏覽Target類分層結構，并發(fā)現(xiàn)所有的支持配置，而無需文檔。執(zhí)行合并操作的示例代碼如下所示 〃1)創(chuàng)建Merge Request (合并請求)MergeRequest myMergeReq = new MergeRequest();〃2) MergeRequest(合并請求)的Target字段的類型可以是TargetMerge(目標合并)， 〃因此導出的類被命名為TargetMerge<Business Entity Name (商業(yè)實體名) >。創(chuàng)建 〃從對應于選定Business Entity (商業(yè)實體)的TargetMerge (目標合并)導出的類 的實例。TargetMergeAccount myTargetFirstAccount = new TargetMergeAccount(); myTargetFirstAccount.Entityld = accountld; 〃3)設置Request消息的Target myMergeReq.Target = myTargetFirstAccount; myMergeReq. Subordinateld = subordinateld; myMergeReq.PerformParentingChecks = true;〃4)執(zhí)行Merge Request(合并請求)，Response(響應)消息的類型將是MergeResponse(合并請求)。MergeResponse myMergeRes = (MergeResponse)myService.Execute(myMergeReq);定制與編程模型的集成可以是無縫的，并且與編程模型的剩余部分一致。CRM 系統(tǒng)允許用戶將新的商業(yè)實體添加到系統(tǒng)中。將商業(yè)實體添加到系統(tǒng)中會自動地觸 發(fā)CRMweb服務的服務定義中新的類型和消息的生成并擴展消息的分層結構。這 會允許開發(fā)者使用原始和定制的強類型商業(yè)實體類和接受這些類的消息，并允許對 它們執(zhí)行商業(yè)邏輯和操作。用于創(chuàng)建和實例化已經被添加作為定制的一部分的新商業(yè)實體的另一示例如下 〃用戶公司FAB在名為fab—Vendor的系統(tǒng)中創(chuàng)建了定制商業(yè)實體。用戶獲取了與使 〃用系統(tǒng)實體相同的體驗。//Business Operation (商業(yè)操作)為Update (更新) fab_vendor my Vendor = new fab—vendor(); Key myVendorKey = new Key();myVendorKey. Value = new Guid("{EF687190-6F85-4455-B225-93BF842425DD}");my Vendor .fab—description = "A trusted vendor that provides safety equipment for Bikes";myVendor.fab_preference = new PickList();myVendor.fab_preference.Value = 2;UpdateRequest myUpdateRequest = new UpdateRequest();TargetUpdateFab—Vendor myVendorTarget = new TargetUpdateFab—Vendor();myVendorTargetfab—vendor = myVendor;myUpdateRequest.Target = myVendorTarget;UpdateResponse myVendorResponse = (UpdateResponse)myService.Execute(myUpdateRequest);圖6示出DynamicEntity (動態(tài)實體)610、新的商業(yè)實體及其成員的類圖示。 該類可以是也從BusinessEntity (商業(yè)實體)620導出的CRM商業(yè)實體的剩余部分 的對等體。DynamicEntity 610可以是從BusinessEntity 620導出的新類，允許對實 體實例進行編程，而無需CRM web服務的描述中實體的完整定義均以WSDL語言 可用。DynamicEntity610可以具有表示實體屬性的強類型屬性(Properties) 630和 表示實體的邏輯名稱的名稱(Name)640的數組。由于在WSDL中DynamicEntity610 類作為帶有屬性數組的類來揭示，API的用戶可以創(chuàng)建該類的實例，并將其名稱設 置為任何所需的商業(yè)實體(系統(tǒng)或定制，包括或不被包括在WSDL中)，并將任 何期望的屬性(包括或不被包括在WSDL中)添加到數組中而無沒有任何編譯/設 計時錯誤。在運行時，屬性數組的內容將被評估，如果實體名稱不存在或者不能識 別出數組中指定的屬性，那么就會出現(xiàn)運行時異常。定義DynamicEntity的代碼可以如下 public class DynamicEntity : BusinessEntity {Property[] Properties; public string NameDynamicEntity類610可以將API擴展到超過強類型類，并且可以提供使用商 業(yè)實體并執(zhí)行它們的商業(yè)邏輯的一般和擴展的方法。用戶可以決定使用強類型商業(yè) 實體類DynamicEntity 610格式。用戶也可以決定接收強類型BusinessEntity 620對 象或DynamicEntity 610格式的商業(yè)操作執(zhí)行的結果。DynamicEntity 610的好處是 在設計時，用戶無需完全描述特定商業(yè)實體類型的web服務定義，并且可以開發(fā) 動態(tài)且在開發(fā)時發(fā)現(xiàn)目標CRM實現(xiàn)中的各種定義的商業(yè)實體，并且用于那些實體 (執(zhí)行操作)而無需在設計/編譯時具有它們的定義的代碼。盡管上述文本闡明了許多不同的實施例的詳細描述，但應該理解，本專利的 范圍由在本專利所附的權利要求書的文字定義。該詳細描述應被理解為僅是示例性 的，而不描述所有可能的實施例，因為描述所有可能的實施例是即使不是不可能的 也是不現(xiàn)實的。使用當前的技術或在本專利申請日之后開發(fā)的技術，可以實現(xiàn)許多 替代實施例，這仍然會落在本權利要求書的范圍之內。因此，可以對此處所描述和例示的諸技術和結構進行許多修改和變動，而不 會偏離本權利要求書的精神和范圍。因此，應該理解，此處所描述的諸方法和裝置 只是說明性的，并不是對本權利要求書的范圍的限制。
權利要求
1.一種在顧客關系管理(CRM)系統(tǒng)中使用消息來擴展應用程序編程接口的功能的方法，所述方法包括選擇一操作，其中所述操作是CRM操作；基于所選操作，向CRM web服務傳遞請求消息；如果所述請求消息在所述請求消息名稱中具有商業(yè)實體類型名稱，那么所述請求消息僅對所指定實體有效，則實例化所述請求消息；分配所述請求消息字段；以及執(zhí)行所述請求消息；如果所述請求消息是通用請求消息，在所述請求消息名稱中沒有商業(yè)類型名稱，且所述請求消息具有目標屬性，則實例化所述請求消息；選擇并實例化所支持的目標類之一；分配所述目標類字段；分配所述請求消息字段；將目標類與所述請求消息相關聯(lián)；以及執(zhí)行所述請求消息；如果所述請求消息名稱不包括商業(yè)實體名稱，所述消息也沒有目標屬性，則實例化所述請求消息；分配所述請求消息字段；以及執(zhí)行所述請求消息。
2. 如權利要求l所述的方法，其特征在于，其中所有所述的新消息都是從基 本請求和響應類導出的。
3. 如權利要求l所述的方法，其特征在于，其中所述方法是通過傳遞請求消 息和返回響應消息來執(zhí)行的。
4. 如權利要求l所述的方法，其特征在于，其中所述請求消息由CRM web 服務的客戶機來實例化和構建。
5. 如權利要求l所述的方法，其特征在于，其中所述消息經由傳輸協(xié)議被發(fā)送給所述CRM web服務。
6. 如權利要求l所述的方法，其特征在于，其中商業(yè)操作被分配給商業(yè)實體。
7. 如權利要求1所述的方法，其特征在于，其中通過基于分類所支持的商業(yè) 操作將所述商業(yè)實體分成各分類來創(chuàng)建目標基類。
8. 如權利要求l所述的方法，其特征在于，其中所述目標類分層結構被用于 確定哪些商業(yè)實體支持哪些操作。
9. 一種計算機裝置，包括 一顯示單元，能夠生成視頻圖像； 一輸入設備；一處理裝置，操作上耦合到所述顯示單元和所述輸入設備，所述處理裝置包 括一處理器和操作上耦合到所述處理器的一存儲器， 一網絡接口，連接到網絡和所述處理裝置； 所述處理裝置被編程用于選擇一操作，其中所述操作是顧客關系管理(CRM)操作； 基于所選操作經由傳輸協(xié)議向CRM web服務傳遞請求消息； 如果所述請求消息在所述請求消息名稱中具有商業(yè)實體類型名稱，那么 所述請求消息僅對所指定的實體有效，貝IJ-實例化所述請求消息； 分配所述請求消息字段；以及 執(zhí)行所述請求消息； 如果所述請求消息是通用請求消息，在所述請求消息名稱中沒有商業(yè)類 型名稱，且所述請求消息具有目標屬性，貝U: 實例化所述請求消息； 選擇并實例化所支持的目標類之一； 分配所述目標類字段； 分配所述請求消息字段； 將目標類與所述請求消息相關聯(lián)；以及 執(zhí)行所述請求消息； 如果所述請求消息名稱不包括商業(yè)實體名稱，所述消息也沒有目標屬性，則實例化所述請求消息；分配所述請求消息字段；以及執(zhí)行所述請求消息。
10. 如權利要求9所述的計算裝置，其特征在于，其中所述請求消息由CRM web服務的客戶機來實例化和構建。
11. 如權利要求9所述的計算裝置，其特征在于，其中通過基于分類所支持 的商業(yè)操作將所述商業(yè)實體分成各分類來創(chuàng)建目標基類，并且其中可審閱所述目標 類分層結構以確定哪些商業(yè)實體支持哪些操作。
12. —種計算機可讀介質，適用于存儲計算機可執(zhí)行代碼，以在顧客關系管 理(CRM)系統(tǒng)中使用消息來擴展應用程序編程接口的功能，其中所述計算機可 執(zhí)行代碼包括計算機代碼，用于選擇一操作，其中所述操作是CRM操作；基于所選操作，經由傳輸協(xié)議向CRMweb服務傳遞請求消息，其中所述請求 消息由CRMweb服務的客戶機來實例化和構建；如果所述請求消息在所述請求消息名稱中具有商業(yè)實體類型名稱，那么所述 請求消息僅對所指定的實體有效，貝IJ: 實例化所述請求消息； 分配所述請求消息字段；以及 執(zhí)行所述請求消息；如果所述請求消息是通用請求消息，在所述請求消息名稱中沒有商業(yè)類型名 稱，且所述請求消息具有目標屬性，貝IJ-實例化所述請求消息； 選擇并實例化所支持的目標類之一； 分配所述目標類字段； 分配所述請求消息字段； 將目標類與所述請求消息相關聯(lián)；以及 執(zhí)行所述請求消息；如果所述請求消息名稱不包括商業(yè)實體名稱，所述消息也沒有目標屬性，貝IJ: 實例化所述請求消息； 分配所述請求消息字段；以及 執(zhí)行所述請求消息。
13. 如權利要求12所述的計算機可讀介質，其特征在于，其中所述請求消息由CRM web服務的客戶機來實例化和構建。
14. 如權利要求12所述的計算機可讀介質，其特征在于，其中通過基于分類 所支持的商業(yè)操作將所述商業(yè)實體分成各分類來創(chuàng)建目標基類，并且其中可審閱所 述目標類分層結構以確定哪些商業(yè)實體支持哪些操作。
15. 如權利要求12所述的計算機可讀介質，其特征在于，其中所有所述的新 消息都是從基本請求和響應類導出的。
全文摘要
公開了在CRM程序中擴展API的功能的方法，以及實現(xiàn)該方法的系統(tǒng)。該方法允許用戶使用請求和響應消息來與單個接口通信，該單個接口可以被揭示為CRM web服務模塊，用于通過擴展先前定義的類來創(chuàng)建新的商業(yè)邏輯和操作。
文檔編號G06Q10/00GK101213572SQ200680023935
公開日2008年7月2日 申請日期2006年6月30日 優(yōu)先權日2005年7月1日
發(fā)明者A·加內-希尚內, A·塔卡奇, K·M·懷特伯格, M·J·奧特, M·米勒 申請人:微軟公司