Step up during these hard times

I hope you and your family members are doing well.

During these times of uncertainty and with lot of time in hand, it is important we channelize our time in the right direction so that it helps us to build a vibrant carrier ahead. This is a great opportunity for all of us to sit back, assess and improve our skill sets.

On this regard, here are the top 5 recommendations from my side for the people who are part of Salesforce ecosystem to constantly enhance your knowledge.

1. Salesforce Newsletters & Blogs: Please follow the below links regularly. Apart from frequent updates on Salesforce products and technologies, there is lot of information on how companies are solving the customer problems innovatively during this tough times. These blogs also has great details on how to manage our customer and ourselves better during this pandemic.
• https://www.salesforce.com/form/other/blog-newsletter/?d=701300000021JgNAAU
• https://www.salesforce.com/blog/

2. Learn client side scripting and JavaScript ES 6 concepts: Lightning is all about JavaScript. A developer with a great JavaScript knowledge can become a champion lightning developer.
• https://trailhead.salesforce.com/users/preddy66/trailmixes/client-side-programming-using-java-script – Trailmix created to help learn advanced JS
• https://www.w3schools.com/js/js_es6.asp – ES 6 concepts

3. AURA Lightning/LWC: There is a huge gap of resources with a very good AURA/LWC skill sets in the market. This is a right time for us to catch up on and improve these skills.
a. https://trailhead.salesforce.com/users/preddy66/trailmixes/aura-lightning-components – AURA
b. https://trailhead.salesforce.com/users/preddy66/trailmixes/lightning-web-components – LWC

4. Certifications: This is also a great time to add few more certifications under your belt to endorse your authority on the specific areas of Salesforce.
• https://www.cio.com/article/3188348/7-salesforce-certifications-that-will-advance-your-career.html – This link provides a guide to certifications
• https://trailhead.salesforce.com/credentials/administratoroverview – all the certifications offered by Salesforce are available in this link

5. NextGen Technologies: Salesforce is catching up on the next gen technologies big time and it is important for us to keep up to date on these developments. Salesforce has inducted Block chain, Einstein, Salesforce DX, IoT, Evergreen, LWC open source etc.. into their platform. These technologies would be used extensively in the coming days and would redefine the way we solve our customer problems in the future.
• https://trailhead.salesforce.com/users/strailhead/trailmixes/dreamforce-19-developer-keynote-trailmix
• https://trailhead.salesforce.com/en/content/learn/modules/iot_basics
• https://trailhead.salesforce.com/en/content/learn/projects/quick-start-salesforce-dx

Happy learning & be safe!!

— Prashanth —

 

Salesforce: Classic to Lightning Experience Migration

It has been four releases since Lightning experience was first launched by Salesforce. We could see gaps being closed release after release. Lightning experience is maturing & becoming more meaningful. Coming Winter ’18 (Oct 2017), Lightning experience is expected to be on par with Classic & many new modern day CRM features would be available exclusively in lightning alone.

With all these developments, Migrating from Salesforce Classic to Lightning experience trend has already began. In the next year or two, we could see more & more customers opting for Lightning migration.

Based on my experience working on classic to lightning migration projects, I have put together a checklist which could be used during initial assessment & solution design. I would like to share the checklist items in this article,

Custom/Visualforce Components:

• Analyse the UI components used in the Visual force pages & check for the availability of equivalent component in Lightning Design System (LDS) referring this link
• Check for the usage of the third party Java script (JS) frameworks and decide if those frameworks are supported in Lightning. Lightning doesn’t support all JS frameworks and the list of supported JS frameworks can be found in this link
• Custom pages can also be developed using UI development apps such as SKUID, Grid Buddy, etc.. check the availability & impact of using these kind of tools in Lightning. For Instance Grid Buddy is not yet compatible with lightning. In such scenarios we may have to look for equivalent lightning ready apps or develop custom lightning solution using LDS
• Salesforce classic’s Custom Java Script Buttons functionality is not supported by Lightning. Refer to this link to find the alternatives in Lightning Experience
• Custom components developed using lightning & are added to Record detail page will only appear in Desktop Experience but doesn’t appear in SF1 app. For the customers with similar requirement & the need for custom component to work in both Desktop & SF1 app, we need to plan an additional effort of 5 to 20 % (based on complexity) to make the component work in SF1 app using Lightning Actions.
• If some of the existing visual force functionality can’t be migrated to Lightning, we can take an approach of making Classic pages look like Lightning. This option should be exercised only for the must have features which can’t be migrated to Lightning due to the current limitation of LDS

Standard Extensions:

• Check if the customer is using Salesforce Classic Mobile app which will retire on Dec 1st 2017. Review the app, based on the business requirements & customizations decide if the app can be converted to/created as SF1 or Custom Mobile app (Mobile SDK) solution
• Check for the Communities, type (partner or customer), customizations and the business requirements. These are to be recreated using Salesforce Lightning Bolt community framework
• Open CTI functionality, is supported in both Classic & Lightning experience but there are some functional differences which are listed in this link.

Admin/Config:

• At present, all the Standard objects available in Classic are not present in Lightning. List & Review the list of Standard Objects which are currently used by the customer, ensure the availability of these objects in Lightning & plan the next steps accordingly
• Lightning Record Home pages at present are quite simple & only shows couple of List views. If the customers org. Record Home Page has multiple views (Config./Customization’s) these views won’t be switched to lightning automatically. We may have to consider developing custom Record Home Page app in this scenario
• Calendar Sharing and Ownership is not supported in Lightning yet. This is a major limitation for the customers in need of this frequently used feature
• If the customer is using any apps, see if these apps in the app exchange are available in lightning ready mode. If not do the following & decide,
  1. Check the time frame by which the existing app will be made lightning ready
  2. Check for similar solutions in app exchange which performs the same functionality
  3. Considering developing a custom Lightning solution to meet the similar requirements

Generic:

• Refer to roadmap to see if missing functionalities are coming in the upcoming release. Design solution considering road map & appraise customers accordingly. The current road map can be found here
• Be familiar with the Limitations & known issues in Lightning. The current list is available in this link

Classic to Lightning Migration activity can range from simple to quite complex. Based on the modules implemented in the project, we may have to cover multiple functional areas. In this blog, I have only covered the functional areas which were part of my projects. Though this checklist is not exhaustive it serves as a good reference to understand the approach & the key areas to be focused during Migration assessment & solution design phases.

Do share your feedback & migration experiences 🙂

.. Prashanth N ..

Salesforce: Mobile Apps Development Approaches

After a gap of over 6 months, i’m back to blogging 🙂 and this time on Salesforce Mobile apps development approaches.

These days it is difficult to find a person without holding a mobile phone in their hand. People of every stripe create and consume data on an ever-increasing variety of connected devices.

Considering the rapid growth story of the mobile devices, businesses are investing on mobile app development to promote, advertise, sell, service, deal with client/partner, etc. from the mobile apps. This trend is evident in CRM space as well. Going mobile has become a key business requirement in most Salesforce implementations nowadays.

The Mobile apps can broadly be classified into two categories,

• Consumer apps: developed for Customers
• Business apps: developed for business users (Employees/Partners -> Sales, Marketing, Service & Operational users)

To meet the challenge of running businesses on mobile devices, Salesforce provides the Salesforce Platform (App Cloud Mobile).

As part of this article, I intend to cover the following two approaches/options provided by Salesforce for building & deploying mobile apps and considerations to be applied to choose the right approach.

1) The Salesforce1 App:

• This is the fastest way to deliver mobile app for employees
• Already built and made available in Apple App Store & Google Play Store by Salesforce
• Offers simple point-and-click tools for administrators and the Lightning web development platform for advanced developers to customize & extend the Salesforce1 app

2) Salesforce Mobile SDK:

• Gives developers the tools to build the customized user experiences
• Native & Hybrid custom mobile apps can be developed with this option
• These apps can target employees, customers, or partners
• Custom Apps can be built using Device Native or web technologies (HTML 5, JavaScript frameworks like React Native, Cordova, Ionic and Polymer)
• Provides same grade of reliability and security found in Salesforce1

Comparison & Considerations:

Comparison Parameter	Salesforce 1	Mobile SDK – Native	Mobile SDK – Hybrid
Development effort/cost	Medium	Very High	High
Maintenance/changes	Easy	Very Complex	Complex
Branding	Very Minimal	Customizable	Customizable
User Friendliness	Less Intuitive	Intuitive	Intuitive
Navigation	Fixed	Customizable	Customizable
Offline	Available	To be Custom built	To be Custom built
Access to app using Web browser	Not available	Not available	Available
Platforms Support	iOS, Android & Windows	iOS & Android	iOS & Android
App/Play Store Subscription	Not Required	Paid Subscription	Paid Subscription

 

Conclusion:

With Salesforce1 approach, mobile solution can be deployed faster on all the three popular mobile platforms with minimal effort. But downside with this approach is limited support for app customization to meet Corporate branding needs (such as UI themes, Navigation, User Friendliness & also users end up downloading Salesforce app not the company app from the Play Stores, App Store & Windows Market place)

Mobile SDK – Native approach, Native apps typically have better performance with rendering and animations & also “feels right”. Look and feel is consistent with most of the other native apps on the device and end user can pick up the app navigation & use the app faster. The major disadvantage with this option is, a separate code base has to be created & maintained for each platform. Also, native apps can’t be made available on browser.

Mobile SDK – Hybrid approach, hybrid apps are platform agnostic & this is one of the main appeals of a hybrid app: you build it once and then you release it across multiple platforms. We have a complete flexibility to design the app meeting corporate branding needs. Moreover, we just have to maintain a single code base. And these apps can also be made accessible on browser for the users who don’t have access to Smartphones.

I hope these inputs helps you to better understand various Mobile app development approaches, the merits & demerits and the parameters to be considered to choose the right approach

.. Prashanth N ..

Salesforce: Apex Callout Vs Outbound Messaging

As we know, Salesforce provides the following features to implement Outbound Integration(s),

• Apex Callout
• Outbound Messaging (OM)

While designing a solution, it is very important that we fully understand the capabilities of these features to make a right design choice. As part of this blog article, I intend to share the capabilities along with considerations to be applied to choose the right Outbound Integration feature.

1. Apex Callout, enable Apex to invoke external web services. This allows you to connect to 3rd party web services such as Google, Amazon, Facebook, and any other external web service.

Capabilities:

• Callout requires familiarity with Apex coding
• Transaction failure & retry logic should be explicitly coded
• Supports both SOAP & REST API Invocation
• Sync & Async requests handling is supported
• We can send multiple records (including related) in a single transaction
• Apart from Basic & Certificate-Based, other authentication (s) can also be implemented using “Named Credentials”
• Sync Callouts should be considered only in the following scenarios. Otherwise consider using Async callouts.
  • When the Target System guarantees the faster response time (SLA of ~ 3 to 5 seconds)
  • Transfer minimal data
• Callouts are generally launched from Triggers and Custom Buttons/Links
• SOAP & REST API Callouts can be implemented using WSDLtoAPEX and HTTP Objects

Consider using Callouts in the following scenario(s),

• Target system Web Services (SOAP/REST) can be directly consumed within Salesforce
• Sending Multiple/Multiple Related records
• Specific authentication method (say Basic) is required

2. Outbound Messaging (OM), allows you to specify that changes to fields within Salesforce can cause messages with field values to be sent to designated external servers.

 Capabilities:

• OM can be implemented using Point & Click tools without having to write any code in Salesforce
• Can be invoked from Workflow Rules, Approval Processes and Entitlement Processes
• Retry logic to reprocess failed records comes Out of the box. If the endpoint is unavailable, messages will stay in the queue (Salesforce) until sent successfully, or until they are 24 hours old. After 24 hours, messages are dropped from the queue. If a message cannot be delivered, the interval between retries increases exponentially, up to a maximum of two hours between retries
• Sends configured fields in the form of XML SOAP message to the specified end-point
• The destination end point should be setup in a specific way for it to accept the contents of the SOAP message being sent. We won’t be able to use existing web services of the Target system.
• The request & response format is predefined by Salesforce. Our solution should align to this format
• Only certification based authentication is supported
• We can only send single parent record fields in the SOAP message. Additional web service transaction should be issued back to Salesforce (from custom solution) using the session id sent in the SOAP message to get additional (related) records
• Max of 100 notifications will be sent in a single outbound message
• Only Async transactions are supported

Consider using OM in the following scenario(s),

• Leverage point & click tools, avoid coding
• If we are integrating with Target system using the intermediate (custom) service for any reasons, we could consider using OM feature

Hope this article helps to make a right choice while designing a solution for outbound integration. If you have any specific comment on the capabilities and considerations, please do share.

..Prashanth N..

Salesforce Integration & Customization Capabilities Overiew

Integrating Salesforce with external systems (Ex. ERP); building custom web extension apps/batch programs to meet the specific business requirement is quite common when we work on large scale Salesforce projects.

Before we attempt to develop such solutions, having a good understanding of various integration (+custom extension & batch) scenarios we generally come across and the provisions provided by Salesforce to implement each of these scenarios helps us to pick the most efficient, scalable & reliable implementation approach.

The objective of this blog article is to list all possible integration (+custom extension & batch) scenarios and to introduce/brief various provisions provided by Salesforce to implement each of these scenario.

General Integration (+custom extension & batch) scenarios,

1. Outbound Integration
2. Inbound Integration
3. Automated Batches
4. Bulk Data Management/Migration (Export/Import)
5. Custom Web Extensions (Web – Mashup, Links, Applets, Tabs,..)
6. Custom Mobile Solutions

Now let us go through the provisions provided by Salesforce in order to implement each of the above scenarios,

• Outbound Integration: can be implemented in Salesforce using the below features,
  • Apex Callouts
  • Outbound Messaging

• Inbound Integration: The following options are available to implement Inbound Integration,
  • SOAP Web Services API
  • REST Web Services API
  • Apex Web Services

These options can also be used in combination with Outbound Integration approaches for some specific solutions.

• Automated Batches: We can write the automated batches using APEX & run these batches as per the required frequency using APEX Scheduler. Triggers & Process Builder can also be considered for automation based on the requirement.

• Bulk Data Management: The following are the available options for Bulk Data Management. Based on the data volume, right option should be decided.
  • Import wizard
  • Data Loader
  • Batch Apex
  • Bulk API

• Custom Web Extensions (Web – Mashup, Links, Applets, Tabs,..):
  • To develop a custom web page/app Salesforce provides Visualforce, Lightning Design System, AURA, APEX development framework
  • To render the custom web pages developed outside salesforce within Salesforce, Canvas & Connected Apps features can be leveraged

• Custom Mobile Solutions: Salesforce provide Mobile SDK to build custom Mobile Solutions. The Salesforce Mobile SDK supports three development approaches for building mobile apps: native, HTML5, and hybrid.

Factors to be considered to pick the right approach among the available options will be covered in the subsequent blogs.

Prashanth N

How Salesforce Lightning Design System is special

Developing a custom mashup (web page) screens in medium to large scale CRM implementation is quite common either to meet unique custom business requirements or to render the data from external systems (being within CRM) to facilitate a comprehensive/single view to the CRM users.

If a CRM system doesn’t provide a framework to develop these custom UI extensions, generally we choose to use J2EE/.Net/PHP technology stack to develop these custom extensions (mashup).

Of late most CRM apps work in desktop, tablets & smart phone devices in wide variety of browsers & mobile apps. One key expectation when we develop custom extensions is to make them work in all browsers/devices on which CRM works. Also, make them look similar to standard CRM pages.

Meeting this key expectation using a custom technology stack is going to be time consuming & quite challenging (if not impossible) though we have many client side frameworks that are platform/device neutral. Many times we need UI design experts to design complex mashup screens.

If we pick the wrong technology stack or if the mash ups are not designed following the best of the design practices, the CRM usability &  performance will be affected.

To overcome all of these pain points; many a times we wish if CRM could extend a framework (used to build the CRM application itself) and can the framework be made available in the programming language which a developer is familiar with?

The very thought of using a CRMs native framework for custom extensions development is quite exciting as it makes the life of the developer easy.

Salesforce does exactly that with Lightning Design System (LDS), the framework used for the development of Lightning experience & Salesforce 1 (SF1) Mobile app.

This framework provides 80% of UI components used in  Lightning & SF1 Mobile. And the developer can choose to use any of the UI components they would need in their Mashup screens/ Lightning apps development. The sample codes & detailed documentation will only help to accelerate the learning & development process.

The following are some of distinct benefits of using LDS in custom mashup screens/Lightning apps development,

• LDS looks similar to HTML code making it easy to adopt
• App development becomes easier
• Make your app look like salesforce Lightning experience & SF1 Mobile
• Build apps faster
• Facilitate reusability
• LDS is Optimize for best practices and make bad practices harder to implement
• Accessible by design : Supporting WCAG 2.0 and Section 508 standards
• Developers can design any complex mash up screens on their own without having to depend on the expert UI designer

Are you excited & want to start with LDS learning, here are the quick links,

https://lightningdesignsystem.com/

https://trailhead.salesforce.com/en/module/lightning_design_system

Good luck & happy learning LDS!!

Prashanth N

 

Oracle Sales Cloud Custom Extensions: All new possibilities

While implementing medium to large scale Oracle Sales Cloud (OSC) CRM projects, developing Custom Extensions/Batch Automation solutions to meet specific business requirements of the customer can’t be avoided.

Generally, these Custom Solutions are developed leveraging SOAP/REST API integration capabilities using J2EE/MSFT/PHP technology stack.

In the past, there was a limited provision to host/run such custom solutions within OSC. Which means customer should procure & maintain the hosting server. This not only incurs additional cost but also defeats the purpose of choosing SAAS solution. This is one of the biggest complaint/pain point customers have expressed over the years whenever we propose the custom solutions.

With the latest releases of OSC, we see all new possibilities to develop & run the custom extensions/batch automations kind of programs within OSC.

In this article, I would provide insights on how do we leverage various integration capabilities & hosting possibilities provisioned by OSC to develop custom solutions which can run within OSC.

The following are the hosting possibilities within OSC,

1. Web Center: Supports hosting of JS/HTML file. These files can be made accessible in public or only within OSC
2. Narrative Reports: We can write JS/HTML code here
3. OSC Administration/Configuration: Supports working with OSC/External Web Services in this area using Groovy Scripts

And the integration capabilities offered by OSC to develop custom extensions & automated batch programs are,

1. SOAP
2. REST
3. Groovy

SOAP is the traditional mode of integration mechanism been around almost since the inception of OSC; REST API is introduced in the latest releases to align with current trend offering lots of flexibility to develop custom solutions

And we have Groovy which is another option to make web service calls from within OSC Administration/Configuration area. Using Groovy, we can perform CRUD operations (both parent & child objects) on records in specific triggers events(like Create, Update, Delete,..). We can also call external web services/OSC SOAP WSDL from within OSC Configuration area using Groovy.

So the new approach to develop custom extensions could be to use Client Side technologies(Java Script) and SOAP/REST API. This solution can then be hosted within Web Center/Narrative Reports.

Also, if we can effectively & intelligently leverage full potentiality of Groovy Scripts; over 90% of requirements for which we end up developing custom automated batch programs can be implemented only using Groovy Scripts.

So considering these varied integration capabilities & hosting possibilities, it is now possible to develop custom extension solutions to OSC without a hosting server. This is a step towards a true SAAS model, run everything within Cloud, Save Cost and keep customer happy.

And the matrix shown below can be used as a quick reference guide while arriving at a solution for any of the custom extensions,

Oracle CRM On Demand: Search Optimized Fields

In CRM OD, we have two types of Optimized fields,

Indexed Custom Fields:

1. These are special fields that improve the response time during a search or when
2. Indexed custom fields are preconfigured in the Oracle CRMOD database
3. We can change the labels on the indexed custom fields to suit the usage, but not the integration tags
4. These fields are available to be accessed using both WS 1.0 & 2.0
5. The following table shows the Custom Index Fields supported for each of the Record Type

Note: For all Custom Objects, some fields use different naming conventions to those listed in the previous tables:

Index Picklist 6 = Type

Index Short Text 1 = Quick Search 1

Index Short Text 2 = Quick Search 2

Index Long Text = Name

Custom optimized fields:

1. Unlike Custom Indexed fields, Custom optimized fields don’t come as preconfigured fields. Instead while creating a new custom field, we have a provision to mark a custom field as Optimized
2. Before creating a new custom field, we should perform a detail assessment on the possibility of using the field as a search filter parameter either in Web services, Reports or Lists. Because a custom field can only be marked as “Optimized” at the time of creation
3. These fields can be accessed only using WS 2.0
4. The following table shows the Custom Search Optimized fields supported under each object by data type

Identifying the Optimized fields

We can identify the “Indexed Custom Fields or Custom Optimized” fields for a given Object using the following approaches,

• Using “new List page” of CRMOD UI: Indexed Custom Fields or Custom Optimized fields are marked in green in this page. It is very easy to identify the search optimized fields from this screen

• Navigate to Admin -> Application Customization -> Record Type (Account) -> Record Type (Account) Field Set up. In “Integration Tag Web Services v2.0” column, Integration tags with “Index or Optimized” keywords in it are search optimized field

 

Note: It is recommended to use only these search optimized/indexed fields as Web Services, Reports & Lists Filter parameters

Custom Fields Migration to Optimized fields

If we are already using a non-optimized field as a filter either in Web Services, Reports or Lists; After the detailed analysis if we decided to do the migration from a custom field to an Indexed Custom or Custom Optimized field to increase the performance. Before migrating the field, we have to take care of the following,

• Data migration for the existing records
• It is highly possible that the custom field might be used in one or all of these CRM OD modules. Perform a detailed analysis & change the affected modules to point & work with newly configured optimized field.
  a. Web Services components
  b. Workflows
  c. Rules & Validations (Under Field Management)
  d. Reports
  e. Lists
  f. URL parameters in Web Links, Applets & Tabs
  g. Integration Event Queues
  h. Data Rules & Assignment

 

Mobile Business Apps – How to choose the right development framework?

While developing mobile business apps, choosing the right mobile application development framework is a key decision making process. It is highly important that, the decision maker invests significant time upfront towards making the right decision considering the factors such as application type, domain, target device platforms, UI & UX design, usability requirements,..

When the right mobile development framework is selected after considering all of the above mentioned key parameters, we can reasonably be assured that the mobile app can be implemented & maintained within the budget & timeframe meeting customer business needs.

In this article, I would like to share some of the available mobile app development approaches, frameworks, its pros & cons.

A few mobile approaches;

1. Mobile Web: An app specifically developed for limited real estate and mobile usage on the go. Ex: m.facebook.com!
2. Full Native: An app fully developed in the platform’s frameworks, they offer the best experience. However developing for multiple platforms usually means writing the app multiple times. Example: Apps developed using Android, iOS SDK’s.

3. Hybrid:
An app built using a mix of native and web technologies. Hybrid frameworks comes in two flavors,

a. Free and open source framework: The following would be mobile app development approach with this option:
• Develop App UI/pages using UI Development frameworks such as WebIx, Bootstrap, Sencha, Ionic, Intel® XDK,..
• Use Apache Cordova to access the Mobile Device features such as Camera, Dialer, Geolocation,..
• Build the Mobile app to the target platforms (Adroid, iOS,..) using frameworks such as Phone Gap, Titanium, ..

b. Licensed frameworks: Example: Oracle Mobile Application Framework (MAF). Licensed frameworks come prepackaged with inbuilt UI controls, API’s to access device features and the hybrid app build framework as well

Pros & cons of the above popular approaches:

Full Native:

Pros:
• OS default themes can be leveraged to design the app UI & Navigation in line with native device UI
• More control in accessing the device features and functionalities

Cons:
• Talents with technical competencies such as Java, Objective C & .NET are required to develop Native apps for Android, iOS & Windows platforms
• Separate front end code base has to be developed for each of the platforms
• Development/Maintenance time & cost increases significantly to deploy the app in different platforms

Hybrid – Open Source

Pros:
• Write Once & Run Anywhere (WORA)
• Write code in familiar Client Side programming languages such as Java Script
• Significant reduction in development & maintenance cost compared to Full Native approach

Cons:
• App UI & Navigation may not match the standard Mobile OS themes
• Detailed Client Side Technology competency (Java Script, HTML 5, CSS 3,..) & Knowledge on UI development frameworks (Bootstrap, Sencha, WebIx,..) is required to develop complex business apps using this model

Hybrid – Licensed (Ex. Oracle MAF)

Pros:
• Write Once & Run Anywhere (WORA)
• Significant reduction in development & maintenance cost compared to Full Native approach
• Extensive ready to use UI controls are available using which complex web pages can be easily designed & developed
• Prebuilt Binding tools can be used to automatically bind the web pages with the backend data feeds (such as DB, SOAP or REST based services)
• MAF Plugin is available for both Jdeveloper & Eclipse IDE’s
• Significant reduction in development & maintenance cost compared to other Mobile App development approach

Cons:
• App UI & Navigation may not match the standard Mobile OS themes
• Available in Licensed mode only
Note: There are other Licensed Mobile application development frameworks in the market. Since I have experienced on using Oracle MAF, I have considered this as an example in this article.

There are no hard-and-fast rules which can help us to decide on the development framework. Every mobile app development initiative has to be analyzed & evaluated in detail considering the above factors to arrive at the right development framework suiting the context.

I hope the information in this article will help you to evaluate & choose the right mobile application development framework to develop your mobile business apps.

— Prashanth N

Oracle CRMOD – REST API

In R27, Oracle has released much awaited “REST API” to develop Custom Extensions on CRMOD application. This blog article covers overview of REST API, comparing it with SOAP and discussing the benefits.

1. REST – Introduction
• REST stands for Representational State Transfer and is an architectural style that makes use of existing technology and protocols of the Web, such as HTTP and JSON.
• A REST API allows you to send data requests and receive responses over an HTTP interface.
• REST requests and responses include a header and a body.
• The header defines the operating parameters of the interaction and contains metadata, such as HTTP methods (GET, POST, PATCH, and DELETE) or encoding information.
• The body contains data that you want to transmit over the network, to use it according to the instructions in the header. The body can also remain empty.

2. CRMOD REST API – Overview
In R27, Oracle published REST API to facilitate developing custom extensions to Oracle CRM On Demand by using the GET, POST, PATCH, and DELETE HTTP methods.

3. REST API – Fundamentals

3.1 Requests: CRMOD REST API request can include the following information:
• A request URL
• Object Name
• HTTP Method Name (create, retrieve, update, or delete)
• Header information – fields, content type, format,..
• Optional query/filter parameters
• Optional sorting parameters

3.2 Responses: The response can include the following information:
• A HTTP status code
• The response body

3.3 Authentication:
• To send REST API requests and receive REST API responses, we must be successfully signed in to Oracle CRM On Demand
• If we are not signed in to Oracle CRM On Demand and, try to send a REST API request, then the REST request is redirected to the Oracle CRM On Demand login page
• REST API call inherits the same Data Access & Visibility settings of the logged in user

3.4 REST API Request Rate Limits
• CRMOD’s REST API resources can be shared by multiple users
• CRMOD limits the number of REST API requests that a user can simultaneously execute during a defined time period
• By default, the REST Request Rate Limit is 30 requests for each minute
• The calculation of the REST request rate begins with a user’s first request and refreshes every minute
• If a user session expires, or if the user signs in again, then the calculation begins again from the minute of the first request

3.5 REST API Privilege
• To send requests and manage RESTful Services Integration, your user role must include the privilege: Restful Services Integration
• Contact Oracle Customer Care to enable the privilege

4. REST API – Comparison with SOAP

4.1 Objects/Operations Support:
• All the Core & Child Objects supported by SOAP are supported by REST
• Service APIs – Only Mapping Service equivalent (Describe) is supported in REST. Others such as Deleted Item, IEQ,.. are not supported
• No Support for Administrative Services
• Upsert Operation is not supported

4.2 Others:
• The Oracle CRM On Demand REST API supports only JSON encoding for the request body
• The Oracle CRM On Demand REST API resource can be accessed by both the default tag name and the custom tag name that you create. For example, if Accounts has a custom tag name, Companies, then Accounts can be accessed by both of the following URLs:
http://server/OnDemand/user/Rest/027/Accounts.
http://server/OnDemand/user/Rest/027/Companies
• Finder parameter is supported only for top level objects
• Special Search Fields – Some field names are prefixed with CI_ to denote that they are special fields that provide better search functionality
• The Oracle CRM On Demand REST API uses Oracle CRM On Demand authentication. You must be successfully signed in to Oracle CRM On Demand to send REST API requests and receive REST API responses.
• Oracle CRM On Demand REST API to be used for interactive operations with Oracle CRM On Demand. For Oracle CRM On Demand bulk operations, use Web services

5. REST API – Benefits:Using REST API we can develop extensions that runs within CRMOD (Web link, web applet, web tab,..) using Client Side Technologies such as JavaScript and host them with in CRMOD using Client Side Extensions (CSE). The following are the benefits,
• REST requests can only be triggered from within CRMOD and the authentication & access control is automatically handled by CRMOD based on the user profile from which the request is triggered. No need to explicitly pass the SSO Token/User credentials in the REST request. This results in improved security and performance of web services calls
• Web services allotments cost can be reduced using the CSE based solutions
• REST API is much simpler & faster compared to SOAP
• Saves initial & ongoing maintenance costs associated with Hardware & Software (Application Server) required to deploy Java/.Net based solutions
• CSE components reside within CRMOD app and hence offers the following additional advantages,
o Web Services calls respond faster since the request are initiated from the same server rather than third party hosting server
o CSE Components and web services calls inherits the security practices of CRMOD
• While designing and developing CSE based solutions, leading responsive design frameworks such as (Bootstrap, WebIx, Sencha,..) can be used to develop the custom web pages. With this, all custom web pages can be accessible using desktops, mobiles and tablets

6. Technical Competency Required:
• Basic Knowledge on REST
• Advanced Java Script
• Angular
• Knowledge on HTML or any of the UI Development frameworks such as WebIx, Bootstrap,..
• Client Side Extensions
• Knowledge on CRMOD Data Model

I hope this article provided a high level insights to REST API to get started with it. Happy Scripting!!