If you’ve worked for a Fortune 500 company, you know what I’m talking about when I say there are “so many systems” used by IT to support the needs of the business.

But Why? There seems to be many reasons…

  • Legacy Systems that have been supporting the business for years and haven’t yet been replaced
  • Company Acquisitions bring on a whole new slew of systems that take time to integrate and replace
  • Rogue applications built by Business Units that got tired of waiting on IT and did their own thing
  • Specializations in business needs that require special software to be bought or built
  • Personal preferences of decision makers
  • Political agendas of decision makers
  • Build vs Buy philosophies that drive architectural decisions
  • Convincing sales presentations (regardless of how accurate they truly are)

I recently spent a large chunk of my professional time in recent years integrating two powerhouse software packages, and I have to say, it was rewarding, but challenging.

Salesforce.com provides a cloud based platform that historically focused on Customer Relationship Management, providing a robust suite of tools supporting the Sales, Marketing, and Service needs of businesses.

Pegasystems provides a suite of tools historically focused on bringing the power of Business Process Management applications to the enterprise in ways that are easy to implement and adapt over time.

Granted, the above are overly simplified descriptions of both companies, who both offer a host of products and services that often compete with each other in today’s world – but, needless to say, both companies consistently score in the top of their respective Gartner Magic Quadrants, and a Forrester Wave rankings.

Business doesn’t care about all the technical stuff us IT folks agonize over. They want systems that get the job done, and are easy to use.

Cue the ask to integrate these systems. As a Pegasystems Certified Lead System Architect, I’m on the team responsible for the Pega design and implementation. I do love a good challenge.

It was soon clear there would be some challenges along the way, the biggest ones were:

  • Integration tools available
  • Stateful vs Stateless applications
  • Different philosophies brought to the table by each software package

Integration tools available

The first big challenge we faced was determining how to integration these two software packages. Luckily for us, we had some options.

  • Salesforce had a tool they called Canvas that could be used to embed other applications inside of the their systems UI.
  • Pegasystems had a tool specific to Salesforce they called the Pega Process Extender on the Salesforce.com app Exchance
  • Pegasystems has it’s older Internet Application Composer (IAC) paradigm
  • Generic iFrame approach

After spending a significant amount of time and effort trying to make each of these options work, working with both vendors and performing several internal POCs, we ran into a big problem.

Stateful vs Stateless

The Salesforce UI was completely stateless, displaying all the data on it’s screen in a pretty static fashion with simple updates to the backend database when data changed.

Pega, however, is built on a stateful model when users are actually in the system performing work, with that work held on a clipboard as they work through a process flow at their own pace.

Pega also handles thread management if the user opens multiple browser tabs or browser sessions.

Salesforce, on the other hand, caused us some pain and could not handle the Statefullness of the Pega UI being displayed via any of these methods while people performed work.

It would appear that if all we were going to do was display static Read Only views of Pega data inside of Salesforce, these methods would work great, but because we wanted users to actually perform work controlled by the Pega application, we’d have to look for a different solution.

Web Services Saved the Day

Ultimately we decided to scrap trying to display Pega UI inside of Salesforce for performing work, and decided to integrate the two systems using web services. This was also a challenge, as now anything you want the systems to be able to do, has to be facilitated by data in these services, so they’re going to have to be robust.  If you think about it, under this type of approach you pretty much have to expose the hundreds of little things the Pega UI and engine does out of the box through services if you want to take advantage of them.

Here’s where we landed

  • Service 1: The workhorse, actions performed that created, modified, or finished work and work related data would use this service. This is everthing from creation, updates, performing local actions, finishing assignments, adding child cases, adding notes, the list goes on and is extensive.
  • Service 2: Search. We needed to be able to search for work via Case ID, Assignment Key, User Assigned to, User Work Party, and Business Context
  • Service 3: Retrieve History & Notes
  • Service 4: Retrieve Creatable Work Objects
  • Service 5: Retrieve Assignee List to faciliate transfers, and user lists when users could select who to assign work to
  • Service 6: Validate Operator. Simple service to take a User ID and tell you if it’s valid, and if so, what role / level of access the user has.

If you’re in Pega 7.1.8 or higher you’re in luck, some very similar Restful APIs have been created for you that perform much of the same functionalities, but we didn’t have that luxury as we built ours out well before. (Coincidence? I’d like to think we helped inspire something pretty cool and useful to everyone!)

In terms of displaying Pega UI inside of Salesforce, we still did that too, but we found out it worked best for Stateless views like read only reports, or simple screen flows designed to completed in one sitting.

Hopefully this was helpful to you, and if you have questions or are interested in doing something similar at your organization, please feel free to contact me!