Looking at the integration strategies with Pivotal CRM for third party applications, I found that a lot of us still use the DCOM interface provided by the Business Server. This means that a lot of times we either host our application on the Pivotal Business Server or create web services to expose the Pivotal functionality to the third party application. With the new enhancements provided by CDC Software around the lines of templates and Web Services Generators, this strategy is becoming easier to implement.
In this post, I will not delve into which strategy is best and should be used as this would largely depend on the specific solution architecture and infrastructure/functional limitations of the implementation environment for Pivotal CRM or the third party application. Having said this, I would like to spend some time elaborating the XML interface that is available to third party applications to integrate with Pivotal CRM.
For those who have not yet worked with ePartner and eService, the XML interface is what is the back bone of these access methods into Pivotal CRM. All data and functional transactions between the ePartner and eService sites and the Pivotal Business Server have been built on the foundation of the XML interface. Surprisingly, even though it is used quite extensively in these access methods, there is not much documentation available regarding it's use... (I know this may not come as a surprise to some... :) ).
Over time, I have had to work with this method to integrate third party applications with Pivotal CRM. I had a tough time getting the correct command format, but at the end I got it and it worked wonderfully. Thus I have dedicated this post to give an insight to how you can get started with this XML interface and get some basic work done for your third party application.
So first things first... what is the architecture of this XML interface? Here is a diagram depicting what this interface is all about and how you can implement this with your Pivotal Implementation. For simplicity, I have only shown the functional components of the interface.
As you can see, the third party application interfaces with the Pivotal Business Server via an HTTP request. The content of the HTTP request is essentially a XML document which follows the Schema set by Pivotal. The request is managed by the Pivotal Business Server XMLServices.asp page and used to run the DoXMLCommand function. We will delve into the schema in more detail in further posts as the discussion can get very lengthy for one post, however the basic architecture of the XML document can be split into two parts.
- The Command: The command element of the XML document contains basic header information regarding the Pivotal System Name, login credentials, connection type as well as the action that is being requested from the server. These action include (but are not limited to) getFormData, saveFormData, getSearchData, getTableData, executeAppServerRule, executeScript, and many more. All these commands give you the ability to perform almost all actions that a Pivotal Client would perform using the Pivotal Business Server.
- The Command Result: The command result element has the content of the data returned from the Pivotal Business Server based on the action required. Thus if the command requested was getFormData, then the result would contain all the data for the form (inclusive of secondary data) as per the active form definition in the Pivotal system. Any errors that occur during the action are also reported in this element.
With the above two top level elements the third party application can request almost any action that a Pivotal Client would request from the Pivotal Business Server.
Before I close this post and start on the more technical explanation of the Command element, let me mention a few notes about the security and connection types used in the XML interface. As we all would know, when we define the security groups in our Pivotal systems, there are many connection types that are present. We define the security settings based on the type of connection used by the user. For example, if the Pivotal user is using the Windows Client, we would ensure that the security settings are on the LAN connection type. Similarly, Client for SmartClient access, Mobile connection type for synchronized systems, Extranet for ePartner and eService and so on.
With the XML interface, we can select which connection type we want to use for our security settings as this connection type is defined as part of the header section of the XML command. The two connection types I have been successfully using are "extranet" and "active client". With these we get the same security for the third party application that the same user would get using ePartner or Rich Client respectively. This would include access to Tables, Active Forms, Searches, Search Result Lists, etc. My recommendation is always to create a separate group for your Application and make the security settings to the group according to the business requirements and integration requirements. One point to note here is that since all the business logic of the server side will run for each of the relevant command actions, the security needs to be complete to handle any business logic dependencies.
In the next post regarding the XML interface, I will go deeper into the XML Command element and discuss the structure of the XML document for a few typical actions.
Posts
