Order View Integration in Salesforce De-Mystified

May 22, 2013 Prabhu Palanisamy

By Prabhu Palanisamy

One of the most common requirements from customers is to provide functionality to search and view orders within Salesforce.com. This step-by-step overview of building order view integrations should help de-mystify the process.

Step1: Building a wireframe

Like any other UI development, UX is very important. Depending on the order processing system there may be a ton of fields which represent order and order line items. There are some to key items to focus on when building a wireframe:

Sample Wireframe

Search Criteria
This is the critical component which takes the criteria provided and make the backend call. Here are a few considerations:

  1. How does the user traverse to the order view page? If the user looks up from Account, then in addition to account identifier, filters like open orders, orders for the last 30 days or top 10 orders helps in query performance.
  2. Use required fields for the search screen. Generic searches with no boundaries can potentially return thousands of rows. Based on the user profile enforcing mandatory fields is key.
  3. Persisting in the order header elements and callout to backend service if we want to know more about the order.

Focus on the field elements to display.

The following questions will help in clarifying the user requirements:

  1. How are the Order headers to be displayed? Layout of the Order Header?
  2. Do we want to display Account level info along with Order Header?
  3. Associations/Relationships with other objects Accounts, Products etc.  – Do we need to display them as read only or as look ups?
  4. Field formatting – Should there be standardization and localization of the field display?
  5. How does the user drill down from Order header to Order details? Should links be provided from header view to navigate more detailed views?

Page Navigation

Something to ask is whether the customer wants to list the records and paginate between result sets.

Step 2: Service definition

Having a middleware helps a lot as this can reduce the complexity of mapping and service invocation from Salesforce. Instead of being just a passthrough i.e simply acting as a broker, middleware could abstract the backend API signatures and expose only field elements required for Salesforce. This makes implementation and maintenance relatively easier.

Performance is king

The service performance makes big difference in user experience. Ideally keeping the performance in 5-10 secs improves the usability. Enforcing strict transaction timeout helps in throwing meaningful error messages back to user before Salesforce times out the request.

Implementing a pagination at the service level helps to put a limit on the number of records returned. The input signature could include page number and page size (number of records per page). Also, in addition to the page result, the output could return query count (total number of records for the search criteria).

Data Structure
Simplifying the data results helps in UI rendering. Standard applications like SAP and Manhattan have complex nested schemas. Parsing the response in Salesforce makes for complex apex development. Middleware could provide the solution with a simplified canonical model.

Step 3: Backend

This is the most important step of all, engaging a Subject Matter Expert (SME) who has in-depth understanding of the system helps in building the proper backend service. e.g SAP ABAP developer to develop custom RFC to fetch order details.

A few important factors to consider:

  1. Explaining the requirements clearly to the backend developer.
  2. Review the mapping fields, search criterias and result sets.
  3. Performance and Service Level Agreement (SLA) for the backend call
  4. Security, data encryption and other compliance requirements.

Step 4:

Depending on the level UI requirements, we could implement using the following ways:

  1. VF custom development and render the data returned from the webservice call. In this model out of the box VF features are used.
  2. Use of JQuery or other JS frameworks. In this model, the data response is returned directly to JS framework and allowing to render the data. This method helps if the service provide supports JSON formats to return the data.

Step 5: Testing and Tuning

Three areas have to be unit tested thoroughly:

  1. The backend services
  2. Service exposed from middleware
  3. Apex classes which invokes the middleware service

Use of tools like SOAP UI can be extremely helpful in testing the services and perform proper test coverage to webservices.

Use of Canvas API:
Instead of custom VF development, one way to provide mashup functionality is to explore the use of canvas API. This allows to have external web pages to be served with Salesforce.com. The Force.com Canvas is a set of tools and JavaScript APIs that you can use to expose an application as a canvas app. This means you can take your new or existing applications and make them available to your users as part of their Salesforce experience.

Caution: This is a brand new feature and still in pilot program but provides promising features to avoid any custom development.


Many times, order view is the start of the many more integrations to get a 360 view of the customer. Order view could be followed by billings, shipments, invoices, Returns etc. Having a well defined integration pattern and reusable services will help in reducing the development costs of future projects.

Previous Article
Mobile Tech Goes Beyond the Office with Workday Financial Business Assets
Mobile Tech Goes Beyond the Office with Workday Financial Business Assets

By Dan Haigh I read a recent article in Forbes.com about American Airlines purchasing iPads to replace pilo...

Next Article
Cloud Metrics Launches on AppExchange
Cloud Metrics Launches on AppExchange

by Naoki Tsukamoto (@nikes63) We are excited to announce that after being run hundreds of times, Appirio Cl...