How to Prepare For and PASS Integration Architecture Designer

It’s third Technical Architect Designer exam covered on the Salesforcememo blog and I’m not slowing down! This time I would like to help you pass Integration Architecture Designer.

 

A Salesforce Certified Integration Architecture Designer assesses the integration requirements necessary to design secure, scalable solutions integrating the Salesforce platform. The designer has experience designing and implementing complex integration patterns to various platforms, as well as communicating the solution and design trade-offs to business and technical stakeholders alike.

Let’s start from basics. What is integration in terms of computer science? Definition says:

The process of linking together different computing systems and software applications physically or functionally, to act as a coordinated whole.

Integration Architectures

 

• Point-to-point
  • Data flows directly from system to system
  • Easy to implement
  • Very hard to scale
• Hub and Spoke
  • Data flows through a central point
  • Single point of failure
  • Adds another place where development must take place and another runtime component
• Enterprise Service Bus (ESB)
  • Distributed services architecture
  • All systems follow the same standards
  • Any new system can plug into the bus, as long as it meets the standards
  • Highly scalable

 

Middleware

 

 
Middleware is a piece of software that connects disparate computer systems and allows them to talk. Functions provided by middleware:

• ETL (Extract, Transform, Load)
• Data cleansing
• Process management

Key middleware concepts:
 
ETL (Extract, Transform, Load)
 
Extract, transform, and load (ETL) refers to a process that involves:

• Extracting data from the source systems. This typically involves data from a number of source systems, and both relational and non-relational structures.
• Transforming the data to fit operational needs, which can include data quality levels. The transform stage usually applies a series of rules or functions to the extracted data from the source to derive the data for loading into the end target(s).
• Loading the data into the target system. The target system can vary widely from database, operational data store, data mart, data warehouse, or other operational systems.

 
Transactionality (Encryption, Signing, Reliable Delivery, Transaction Management)
 
Transactionality can be defined as the ability to support global transactions that encompass all necessary operations against each required resource. Transactionality implies the support of all four ACID (atomicity, consistency, isolation, durability) properties, where atomicity guarantees all-or-nothing outcomes for the unit of work (transaction).

While Salesforce is transactional within itself, it’s not able to participate in distributed transactions or transactions initiated outside of Salesforce. Therefore, it’s assumed that for solutions requiring complex, multi-system transactions, transactionality (and associated roll-back/compensation mechanisms) be implemented at the middleware layer.
 
Queuing and Buffering
 

Queuing and buffering generally rely on asynchronous message passing, as opposed to a request-response architecture. In asynchronous systems, message queues provide temporary storage when the destination program is busy or connectivity is compromised. In addition, most asynchronous middleware systems provide persistent storage to back up the message queue.

The key benefit of an asynchronous message process is that if the receiver application fails for any reason, the senders can continue unaffected; the sent messages simply accumulate in the message queue for later processing when the receiver restarts.

Salesforce provides only explicit queuing capability in the form of workflow-based outbound messaging. To provide true message queueing for other integration scenarios (including orchestration, process choreography, quality of service, and so on) a middleware solution is required.
 

Integration Patterns

 
Salesforce created really informative PDF with main integration patterns and real life use cases for them:

 

Source/Target	Type		Timing		Key Pattern(s) to Consider
	Process Integration	Data Integration	Synchronous	Asynchronous
Salesforce –> System (s)	X		X		Remote Process Invocation—Request and Reply
				X	Remote Process Invocation—Fire and Forget
		X	X		Remote Process Invocation—Request and Reply
				X	UI Update Based on Data Changes
System –> Salesforce	X		X		Remote Call-In
				X	Remote Call-In
		X	X		Remote Call-In
				X	Batch Data Synchronization

Source: http://sforce.co/2nlGjWo
 

Tools Within a Salesforce Org

 
With so many ways to integrate with the Force.com platform, making the right integration choices can often be the key to a successful deployment. In the following sections I would like to explain you a little bit more each of the available options.
 

Outbound Message
 

• Declarative mechanism
• Uses WSDL, SOAP and XML
• Sends asynchronous notifications fired from workflow rules or approval processes
• To view existing outbound messages, from Setup, enter Outbound Messages in the Quick Find box, then select Outbound Messages in the Salesforce user interface.
• If the endpoint is unavailable, messages will stay in the queue until sent successfully, or until they are 24 hours old. After 24 hours, messages are dropped from the queue
• Messages are retried independent of their order in the queue. This may result in messages being delivered out of order
• Because a message may be delivered more than once, your listener client should check the notification IDs delivered in the notification before processing.

 
APEX REST API
 
Use Apex REST API when you want to expose your Apex classes and methods so that external applications can access your code through REST architecture. Apex REST API supports both OAuth 2.0 and Session ID for authorization.
 
APEX SOAP API
 
Use Apex SOAP API when you want to expose Apex methods as SOAP web service APIs so that external applications can access your code through SOAP. Apex SOAP API supports both OAuth 2.0 and Session ID for authorization.

APEX Email Service
 
You can use email services to process the contents, headers, and attachments of inbound email. For example, you can create an email service that automatically creates contact records based on contact information in messages. To utilize that functionality you have to create global class that implements Messaging.InboundEmailHandler interface.

Question:

Universal Containers implemented email-to-case to allow customers to email their support requests. They found that cases were getting created correctly, but the email attachments weren’t attached directly to the cases. Instead, they were attached to the emails under the Open activities related list.

Which two options should be considered to make sure the attachments get attached directly to the cases?

Choose two answers.

1. Choose the option Save attachments under Cases in email-to-case setup options.
2. Write a trigger on the Case to copy/move attachments from email activity to case.
3. Use the Email handler service to extract attachments and create under Cases.
4. Set up web-to-case to automatically create attachments under Cases.

 
Salesforce to Salesforce
 

Mashups & Canvas
 
To simply view the data in Salesforce UI you can look at doing Canvas or Custom Web Tab. Use a Canvas if you need authentication and Custom Web Tab if you need to surface an external website that is unauthenticated.
 

How Different APIs Work

 

 
SOAP API
 

• You can use SOAP API to create, retrieve, update, or delete records.
• Handles medium data volumes
• Uses WSDL, SOAP and XML

Salesforce provides two WSDL files, what are the differences?

Enterprise WSDL:

• The Enterprise WSDL is strongly typed
• The Enterprise WSDL is tied (bound) to a specific configuration of Salesforce (ie. a specific organization’s Salesforce configuration)
• The Enterprise WSDL changes if modifications (e.g custom fields or custom objects) are made to an organization’s Salesforce configuration

For the reasons outlined above, the Enterprise WSDL is intended primarily for Customers.

Partner WSDL:

• The Partner WSDL is loosely typed
• The Partner WSDL can be used to reflect against/interrogate any configuration of Salesforce (ie. any organization’s Salesforce configuration)
• The Partner WSDL is static, and hence does not change if modifications are made to an organization’s Salesforce configuration

For the reasons outlined above, the Partner WSDL is intended primarily for Partners.

REST API

• REST API provides a powerful, convenient, and simple REST-based web services interface for interacting with Salesforce
• Excellent choice of technology for use with mobile applications and web projects
• Uses REST, HTTP, JSON

 
Chatter REST API
 

• Chatter feeds, users, groups and followers
• Provides programmatic access to files, recommendations, topics, notifications
• Chatter REST API is similar to APIs offered by other companies with feeds, such as Facebook and Twitter, but it also exposes Salesforce features beyond Chatter
• REST-based

 
Bulk API
 

The Bulk API is a RESTful API that is optimal for loading or deleting large sets of data. You can use it to query, insert, update, upsert, or delete a large number of records asynchronously by submitting batches that Salesforce processes in the background.

Workbench provides an interface to the Bulk REST API.

Processing data typically consists of the following steps:

1. Create a new job that specifies the object and action
2. Send data to the server in a number of batches
3. Once all data has been submitted, close the job. Once closed, no more batches can be sent as part of the job
4. Check status of all batches at a reasonable interval. Each status check returns the state of each batch
5. When all batches have either completed or failed, retrieve the result for each batch
6. Match the result sets with the original data set to determine which records failed and succeeded, and take appropriate action

 
Metadata API
 

• Allows access to organization’s data model, business logic and user interface
• Provides mechanism for migrating configuration metadata
• SOAP, WSDL and XML

 
Streaming API
 

• You need near real-time notifications when records are created or updated
• Pub-Sub model

 

Security

 
Any call to a remote system must maintain the confidentiality, integrity, and availability of the request. The following security considerations are specific to using Apex SOAP and HTTP calls in this pattern.

• One-way SSL is enabled by default, but two-way SSL is supported with both self-signed and CA-signed certificates to maintain authenticity of both the client and server
• Salesforce does not currently support WS-Security
• Where necessary, consider using one-way hashes or digital signatures using the Apex Crypto class methods to ensure request integrity
• The remote system must be protected by implementing the appropriate firewall mechanisms

Question:

Which mechanism should an Integration Architect recommend to make a secure, authenticated connection to a remote system that results in the remote system trusting Salesforce?

Choose one answer

1. Use a pre-shared key in a query parameter
2. Implement two-way (or mutual) SSL certificates
3. Utilize CA-signed certificates on the host
4. Encrypt the payload with a shared key

Question:

What two things should an Integration Architect consider when building a Visualforce page that makes client-side callouts to multiple domains that may violate the browser’s same-origin policy?

Choose two answers

1. Utilize the Canvas SDK to perform the callouts
2. Set up CORS to whitelist all domains that the client scripts communicate with
3. Ensure each JavaScript resource communicates only with its origin
4. Set up Remote Site Settings for all domains that the client scripts communicate with

Question:

Universal Containers wants to ensure Salesforce will only accept secure connections from their ETL tool. How should calls to a custom Apex web service be secured?

Choose one answer

1. Two-Way SSL
2. VPN
3. IP Whitelisting
4. Profile Security

 
Named Credentials
 
Salesforce manages all authentication for callouts that specify a named credential as the callout endpoint so that you don’t have to. You can also skip remote site settings, which are otherwise required for callouts to external sites, for the site defined in the named credential.

TLS