In an earlier post we summarized the key concepts behind SnapLogic “Snaps.”
- Snaps are modular collections of integration components built for a specific application or data source.
- They shield business users and developers from much of the complexity of the underlying application, data model and service.
- Snaps are easy to build and modify and are available for analytics and big data sources, identity management, social media, online storage, ERP, databases and technologies such as XML, JSON, Oauth, SOAP and REST.
You can check out what Snaps are available on the SnapStore.
In this post, we’ll cover a related topic from our technical whitepaper: Web Standards. Purpose-built for the cloud, the SnapLogic Integration Cloud has embraced modern technologies and made them a native part of the platform. JavaScript Object Notification (JSON) and Representational State Transfer (REST) are regarded as the key building blocks of our scalable web architecture.
JSON:
The internal representation of data inside a SnapLogic Integration Cloud pipeline is in JSON format. This lightweight data-interchange format provides the cloud integration platform the flexibility to handle structured as well as unstructured data. In Greg Benson’s post Technical Advantages of JSON-centric iPaaS, he notes:
“At SnapLogic we recognize that while modern web services and data stores are heading toward JSON, businesses still use relational databases for normalized, transactional data. The great thing about documents is that they are a superset of relational records. When converting a record into a document we combine the column names from the schema with the field data to create a key/value document. This allows us to consume records and output records as needed, but still get all the advantages of the document model. Furthermore, we support traditional ETL operations such as JOIN, AGGREGATE, and SORT on documents. This allows primarily relational data to be treated seamlessly, but also extends these ETL operations in a way that support hierarchical documents.”
REST:
Each deployed pipeline by default is eligible for invocation with the REST protocol. An administrator exposing any pipeline as an API is a matter of flipping a switch. The administrator will need to grant requisite permissions (authentication and authorization) to clients. Typical clients of these APIs will be trading partners and mobile consumers looking to consume business data or business processes. For example, a trading partner may need to have real-time insight into inventory to ensure that they can make commitments to their customers that expects a certain product inventory levels. Or, a customer may want to check the status of their order through their mobile application; this lookup involves querying your shipping module with the shipment ID.
In this Integration Developer News review of the SnapLogic Integration Cloud Spring 2014, Maneesh Joshi notes:
“We?ve found customers are really interested in APIs for a number of reasons. They want to expose their business process as APIs and people find they can also use them to monitor the performance and reliability for their cloud integration [with off-premises SaaS].?
He describes SnapLogic’s API strategy this way:
“For developers, you can turn a SnapLogic pipeline quickly into an API, which lets them cut way down on coding and complexity on integrating mobile apps with backend systems. For operations, we provide a graphical dashboard that lets IT monitor these integrations for scale, performance and whatever.”
Download this technical white paper to learn more about the SnapLogic Integration Cloud architecture.
