Integrating with Sales Cloud using SOAP web services and REST APIs (Part 2 of 2)

This is part 2 of a two-part blog post that covers SOAP and REST integration with Sales Cloud

In part 1, I covered the topic of invoking Sales Cloud SOAP web services from external applications. In this part, I will cover the topic of invoking external SOAP and REST services from Sales Cloud.

Before discussing the details, here is the outline of this post.

1.  Invoking Sales Cloud SOAP web services from external applications (covered in part 1)

2.  Invoking external SOAP Web Services from Sales Cloud

3.  Invoking external REST APIs from Sales Cloud

 

2. Invoking external SOAP Web Services from Sales Cloud

Sales Cloud Application Composer allows you to invoke external web services from within Sales Cloud. Application Composer is a feature only available in Sales Cloud.

In your Sales Cloud instance, use the Navigator to navigate to Tools > Customization >Application Composer. If you cannot see this navigation, you may be missing privileges. Contact your administrator.

Once in Application Composer, select your Application (say Sales). From Common Setup, select Web Services. You will see a screen similar to the one below where you can enter your WSDL and choose the operation and security.

 

image031

Once you create the web service you can use it to invoke the web services from your UI elements. For example this web service takes in two inputs, Card Type and Card Number and responds with whether the card number is valid for the given card type.

For this scenario we could create two new fields under a standard or custom object as shown in the Application Composer. These fields will be used for capturing card type and card number as inputs from the user. A Third field can be added to provide the response. Using Groovy construct, this third field can be made to invoke the web service for the given two input values.

More information is available at the Oracle official documentation here

The three security options in the figure above translates to invoking web services with one of the following OWSM security policies

o   wss_username_token_over_ssl_service_policy

o   wss_username_token_with_message_protection_service_policy

o   wss11_saml_token_with_message_protection_client_policy

o   wss_saml_token_bearer_over_ssl_client_policy

o   wss11_saml _token_ identity_switch_with_message_protection_service_policy

For external web Services that are not protected with OWSM policies refer the interoperability scenarios at http://docs.oracle.com/cd/E57014_01/owsm/interoperability/owsm-interop-intro.htm

 

In the above example we did not pass any Sales Cloud object attribute as a parameter. In a practical scenario you will be required to pass sales cloud attributes. For example assume that you are in the Accounts screen of Sales Cloud and would like to see the latest stock price of this account. You will want to pass the sales cloud account name or the stock ticker as a parameter to the web service. In this case, if you are writing a groovy script as part of a formula field, you can directly reference the values using the variable (ex. OrganizationName or StockSymbol can be directly referenced and used without having to declare or assign)

Sometimes, you may need to invoke a web service whenever you create or update an object entity. For example, you may want to invoke a webservice whenver a Sales Account is updated. This web service could be part of an integration strategy. For this, create a trigger that fires on create or update of an Account. When the trigger fires, invoke an object function or a global function, which in turn constructs the desired payload and invokes the outbound service that you have already configured. The account payload itself will be available directly using the object name in the trigger or the objection function. For example PartyId can be referenced/used directly in your groovy code. However, when using a global function,  you cannot directly reference the object. If you require the entire object in your global function (which you will use to invoke an external web service), then you can define a parameter (say, p_account) of type Object in your global function and pass “adf.source” for that parameter from the trigger code. Using adf.source will pass the entire object to the global function. It can be used as p_account.PartyId in the groovy code.
You can also refer to the groovy scripting guide at http://docs.oracle.com/cloud/latest/salescs_gs/CGSAC/toc.htm

 

3. Invoking external REST APIs from Sales Cloud

This section is now removed (as of May 2015) since Oracle is revamping REST related features. Stay tuned for more details. This section will be updated again.

The above examples hopefully helped you get a better understanding of Sales Cloud’ SOAP and REST capabilities. Oracle is continuously investing in this area. So stay tuned for more updates!

Comments

  1. hi

    i have deployed my webservice in a Weblogic . I am getting a time out exception when reading WSDL from app composer

    any idea why?
    -SK

  2. Frank Cannon says:

    When using the HTTPClient example, I get the following error when the code is validated:

    Error: Security Violation(s)
    JBO-25152: Calling the constructor for class java.net.URL is not permitted.
    JBO-25152: Calling the constructor for class groovy.util.XmlParser is not permitted.

    Can you provide a solution?

    Thank you

    • Arvind Srinivasamoorthy says:

      As updated in the post above, Oracle is revamping REST related features. The use of class java.net.URL in groovy scripts is blocked. So please stay tuned for the new features in upcoming updates. This section will be live again after the new set of features are available.

Add Your Comment