Check out the other posts in our “Integration 101” blog series:
So far in this “Integration 101” blog series, I’ve covered the basics of integration and tried to untangle some of the misunderstandings around APIs and web services — what they are and what they can and can’t do.
And, speaking of misunderstandings, there’s a lot of confusion about push versus pull when it comes to integration. Who’s pushing and who’s pulling? When do I push versus pull? And does it really matter? It does matter. And it matters more than you might think.
This post will explain:
- The differences between pushing and pulling
- Why it matters
- How to make sure there are no nasty surprises in your next integration project because those terms were not understood
Communication Matters for Integration Projects
I have seen projects almost tank because people used the integration terms “push” and “pull” interchangeably without realizing the implications. In an integration, pushing information results in a very different scope of work for a developer when compared to pulling information. And if I’m pulling information, that results in a very different scope of work compared to someone pulling information from me.
Let’s go back for a moment to the analogy I used in the blog on APIs: the mailbox and the mail person. You have two things that need to exist for an integration to be successful. You need the mailbox: that’s where information is placed and where it’s retrieved. And you need the mail person: that’s the service that “delivers” the mail — puts the information in the mailbox or picks it up from the mailbox.
Simple API Project Definitions: Push and Pull
When information is pushed: it means you’re putting it into another system. You’re pushing information into the mailbox. A great example is sales contacts. If your lead generation system is initiating the movement of contact information, you’re pushing contact information from where your leads are generated into a customer relationship management system like Salesforce.
When information is pulled: that means you’re retrieving information. Using a similar example to the one above, if your CRM is initiating the move of contact information, you’re pulling information from your lead generation system. If you’re taking information out of a database, out of a system, that’s pulling. If you’re putting information into a database, you’re pushing.
Knowing the Difference for Digital Integrations
The problem originates this way. Suppose I say, “We’re NetSuite experts and we can help you do an integration with Salesforce.” You, our customer, say you would like to push information to NetSuite. You’ve just told us your developers know how to develop in Salesforce.
NetSuite has an API. We help you figure out which endpoints — or mailboxes — you want to push information to, and our job is done! By telling us you want to push information into NetSuite, you’ve communicated that Salesforce is the mail person.
Similarly, if you say you want to pull information from NetSuite, you’re still communicating that you want Salesforce to be the mail person. NetSuite has the API — the mailbox — and you’re going to pull (retrieve) information from that API mailbox.
Estimates are made, or developers contracted based on that scenario. But then someone says, “NetSuite, you’re going to pull information from Salesforce.” But that’s not what was agreed to. And that changes everything. Now, NetSuite is the mail person, and we must write code to retrieve the information from Salesforce.
It comes down to grammar. The subject of the sentence: X will pull; X will push — initiates the integration. The subject is the mail person. The verb is the action (placing or retrieving) the mail person performs.
Is It Really That Simple?
At the highest level, yes. It’s really that simple. The mail person places information in or retrieves information from a mailbox. But the devil is in the details. Just because an integration is simple in concept doesn’t mean it will be simple in execution. And making sure all involved parties are on the same page as to who is acting as the mail person and whether they’re pushing or pulling is a huge step in the right direction.
How Can Boomi Help?
Boomi can do both: It can make creating and managing push and pull integrations equally easy. Boomi can pull from NetSuite and push to Salesforce. Or any other set of applications. It’s in charge of both sides of the operation. And it doesn’t require developers to use.
Boomi is a low-code, configuration-based platform with a drag-and-drop interface. Business analysts can be taught to create simple integrations, whether they need to push or pull information. And for complex integrations that may require developers, Boomi provides an intuitive, centralized cloud-native environment that speeds any integration work.
Keep Integration Projects on Track
Build an Integration Requirements Document
Everything we’ve talked about so far in terms of clarifying who’s pushing and who’s pulling should be defined in your requirements document. Here are some other important factors to remember.
- What mailboxes exist? The API exists, but what functionality does it make available? Does the functionality for your use case exist in the API? If not, does the business purpose justify the cost of adding that functionality to the API?
- What skill sets are available to you? If you don’t have a NetSuite developer but you have a Salesforce developer, you’ll probably be pushing and pulling from Salesforce. The beautiful thing with Boomi is you don’t need the ability to code in either because it makes it simple to set up a push or pull integration with just a couple of clicks.
- Do you want event-based data movement? If you’re pushing information, you can define an action or event that will trigger the process of moving information. If you’re pulling information, your only option is batched/scheduled integration.
- Where do you want your business logic to reside? Generally, you want your business logic to reside in the application in which you’ve invested and will continue to invest the most resources.
- What are the cost constraints? If you have internal resources, it will be more economical to do work in-house rather than farming it out. Again, Boomi can be a tremendous asset for your internal developers.
So that’s the basics on push and pull integration. Whenever you start your next integration project, be sure to sort out these terms from the start to ensure there are no misunderstandings about who is responsible for which type of integration.
Integrating your technology is one of the first steps to eliminating data silos and technology fragmentation in your systems. Learn how to avoid these roadblocks in our ebook, Chaos to Order: Connecting a Fragmented Digital Landscape Through Modern Integration
About the author: Nick Mortensen is director of development with Eide Bailly Technology Consulting, a Boomi partner and business advisory firm specializing in the implementation, customization and integration of leading ERP, CRM, and cloud technologies.