According to Internet World Stats, as of June 2019, about 4.5 billion people in the world are connected to each other. I saw this first-hand during my recent trip to India. No matter where you are, you will see some form of connectivity. Even in the most poverty-stricken areas you will see satellite dishes strapped to makeshift shelters. In Maslow’s hierarchy of needs, connectivity seems to have come down to a very basic need -- right above water, food, and shelter.
This is the same for enterprises on the business side, which drive the need for connectivity on the technical side. On the business side, you want to be connected to your customers, partners, and employees. Businesses are often composed of teams of mobile workers working across multiple devices. They need to be able to access data and documents and collaborate from anywhere. Partners want to collaborate in a similar manner, be it sharing customer data, sending in an invoice, or collaborating on a document for a joint marketing campaign.
Why connectivity matters
On the technical side, connectivity as a concept is simple. But be very careful, it is not easy. Technical connectivity, as a concept, means the ability for two systems like an on-premises Oracle Database to “talk to” a cloud SaaS application like Salesforce. This is important because there is a ton of customer data that resides in Oracle that Salesforce needs access to. And when an update to customer data happens in Salesforce, that update needs to “travel to” and be persisted in the Oracle DB.
Now multiply this system interaction many times and imagine the number of interactions that need to happen between the many SaaS applications, on-premises ERP systems, on-prem databases, and custom apps in an enterprise. Add to it partner on-prem and cloud systems that sit outside the firewall and you have a big hairball of connected systems. On top of this, add software versions to all the systems, version deprecation, adding new partners, mergers and acquisitions, and it seems like a mess.
Lastly, think of the fact that even though you can live without connectivity, it is a fairly basic need. Nobody thinks too much about it when it’s there and when it works. However, the absence of it is what reveals its importance, like air. IT doesn’t want to be bogged down with it and app developers don’t want to work on this piece of the plumbing, because connectivity is not rocket science, it does not count as technical innovation, it’s not sexy. The question is, who will do it? These days, vendors are expected to and need to provide a compelling portfolio of out of the box (OOTB) connectors, which are also sometimes called adapters. They need to fit like Lego blocks and connect multiple systems.
Service connectors to the rescue
This got me thinking. There is a limit to the number of OOTB connectors that we can offer to our customers. What if our customers have an esoteric system or a custom-built app for which they need connectivity? I started chatting with our product manager Sorabh Agarwal, who, as always, had a great answer to my question – service connectors. If you have a home-grown or third party API-based application for which there is no off-the-shelf connector, Informatica Cloud Application Integration provides a way to define connectors. You can create “connectors on the fly” in less than 30 seconds, by either importing a WSDL or a Swagger API interface document or creating one manually in a web form. It takes just a few clicks to create custom connectorsthat behaves like a native connector. Or at least this is what Sorabh said, which I wasn’t buying at all. I had been a connectors’ product manager in another life and at that time, every time I would take a request to my engineering team to provide connectivity for a new revision of an existing app, they would wave me off with “at least 3 months” of wait time. How can Informatica do it in less than 30 seconds? I wondered. So I embarked on building my own service connector. And here is what it took me to build a simple, “Calculator Service” connector:
- I logged into the Cloud Application Integration.
- I clicked on New and then Service Connectors (2 clicks).
- I clicked on Service Connector patterns to communicate whether I wanted to work with WSDL or Swagger (3rd click). If there are proprietary APIs exposed, users can either choose to transform their metadata definition using transformers that are available in the public domain to convert to WSDL or Swagger, or they can manually create the service connector.
- Chose WSDL and clicked on Create (4th click).
- Added a name for the connector, a description, WSDL URL, unchecked authentication box and clicked Next (5th click).
- Clicked Next (6th click)
- I reviewed the summary of the connector and clicked Finish (7th click).
- Clicked Save (8th click) and I was done!
- I ended up with the Service Connector information in the Definitions, Actions, and Process Objects tabs. The Definitions tab defines the common properties, e.g., connection properties for this service connector. The Actions tab defines the operations that are available as part of the API definition. Process Objects define the data types that are being used. I could see that the entire connector with actions, input and output fields, parameter types, operations, everything was defined automagically.
- The last bit is to quickly try them out to ensure all went well. I used the Test functionality (see below screenshot) for an action and provided the right set of inputs to the action using “Test With.”
The entire process of creating this service connector literally took me 10 seconds, once I had determined what I needed to build, found the calculator service on Google (which exists as a web service, see image below) and had the WSDL URL handy. Reviewing and testing it took another few minutes. It really is that simple! Try to for yourself for free here (Click here if you are outside of North America).
In our next blog, Sorabh or I will showcase how you can connect two different applications, very easily (again with few clicks) using this service connector technology.
And there is more… not only do we have this technology to build service connectors in seconds, we host more than 300 of these connector samples on a GIT repository with the intent to promote collaboration. While Informatica is dutybound to push more and more service connectors on this repository, we expect Cloud Application Integration community users to help us support in our initiative by pushing their own service connectors on GIT directly.
To learn more, read this very useful and detailed write-up by Sorabh in our network community. And of course, if you want to choose from our more than 300 out-of-the-box connectors, please visit our connectors page.
As usual, Sorabh was right after all.