9 Extending an Opportunity Object with an External Cloud Application

This section discusses how Oracle Sales Cloud extensibility features alone can be implemented to extend an Opportunity object with an external cloud application.


Executive Summary

Use Case This use case highlights extending Oracle Sales Cloud Opportunity object with an external cloud application using Oracle Sales Cloud extensibility tools and technologies. In this scenario, an Oracle Sales Cloud user, such as a sales representative, navigates to an Opportunity Detail page and clicks a hyperlink. The hyperlink leads to a third-party cloud web application. Once the user has completed tasks in the third-party cloud application, a subset of data is persisted into the Oracle Sales Cloud Opportunity object. The user clicks a link on the external cloud web application to return to the specific opportunity record with the updated data.
Implementation Summary Implementation of the integration pattern includes user interface and data model customization in Oracle Sales Cloud using Application Composer. Use web services to retrieve and update Oracle Sales Cloud standard object data. You establish web single sign-on using SAML 2.0 federation between Oracle Sales Cloud and the third-party cloud web application.
  • External third-party cloud application available at the fictitious URL https://myexternalcloudapplication.com/app.jsp
  • Oracle Sales Cloud hyperlink on a transaction page

  • Oracle Sales Cloud custom field EXTCAPP_c for standard objects (the custom field is a text field of 20 characters and stores data from an external cloud application)

  • SOAP-based web services

  • External cloud application

  • Web single sign-on with SAML 2.0

Required Documentation To complete this use case, see the following documentation resources:

About Extending an Opportunity Object with an External Cloud Application

This use case illustrates Oracle Sales Cloud extensibility with an external cloud application using Oracle Sales Cloud Application Composer. Although this use case focuses on extending the Opportunity object with a hyperlink, it is applicable to similar use cases where functionality of other Oracle Sales Cloud standard objects is extended by a third-party cloud application.

External Cloud Application Architectural Assumptions

The following are assumed architectural features of a third-party cloud application you are implementing to extend Oracle Sales Cloud functionality:

  • Your application is web-based.

  • Your application invokes Oracle Sales Cloud web services.

  • Your application persists data into Oracle Sales Cloud.

  • Your application supports SAML 2.0 to establish a Federation Agreement with an identity provider.

  • You application is secure.

  • Your application is configured with the Oracle Sales Cloud tenant-specific endpoints.

Integration Design Considerations for This Use Case

  • Integration of user interface elements

    • A hyperlink on the Opportunity Detail Transaction page of Oracle Sales Cloud that leads to your external cloud web application. The opportunity Id and JWT User Token are passed as URL parameters to the external cloud application.

    • A "deep link" hyperlink on the external cloud application that leads to the Opportunity detail page. The "deep link" hyperlink allows a user to return to Oracle Sales Cloud and view updated data.

  • Web Single Sign-on

    • In a federation circle of trust, the external cloud application is configured as a Service Provider.

    • An external cloud application uses the SAML Assertion token sent by the identity provider to authenticate the user. User identity will be propagated from the identity provider to the Service Provider using the SAML Browser POST SSO Profile. The SAML Assertion token contains a NameID based on one of the following options:

      • Option 1: User Identity value with the NameID format set to Unspecified.

      • Option 2: Email address with the NameID format set to Email Address.

    • Users who are licensed to access the external cloud application are manually synchronized from the identity provider to an external cloud application.

    • User identity will be propagated from the identity provider to the Service Provider using SAML Browser POST SSO profile.

  • Invocation of Oracle Sales Cloud web services by external cloud application on behalf of end user

    • UserDetails Service (findSelfUserDetails) for validating a JWT User Token and retrieving user information.

    • Opportunity Service (getOpportunity) for retrieving opportunity details based on Opportunity Id.

    • Opportunity Service (updateOpportunity) for updating the Opportunity object.

    • Web services are invoked by external cloud application on behalf of end user and is secured with user JWT User Token.

  • Integration of external cloud application data into Oracle Sales Cloud custom fields of an Opportunity object

    • Custom fields in an Opportunity object.

    • Custom fields in an Opportunity Details Transaction page (added to the Opportunity Details work area).

    • Opportunity service (updateOpportunity) to update the Opportunity object, including custom fields.

    • Hyperlink to a specific Opportunity to view updated details after data is successfully persisted into Oracle Sales Cloud.

  • Security

    • External cloud application is secured and periodically tested for security vulnerabilities.

    • Application follows secure coding principles appropriate for the languages and tools used in the implementation process.

    • Designed to protect against Open Web Application Security Project Top 10 vulnerabilities.

    • Static code and Dynamic Security analysis incorporated in development and QA cycles.

    • All end-points of the external cloud application are protected with strong SSL/TLS ciphers.

    • SAML 2.0 implementation of external cloud application security features:

      • SAML 2.0 product, such as Oracle Identity Federation or Oracle Active Directory Federation Service, used by external cloud application is certified and tested by an accreditation authority (Kantara or LibertyAlliance, for example).

      • Support for SAML 2.0 Browser POST or Browser Artifact SSO Profiles.

      • SP-initiated flows. For example, you can directly access your cloud web application URL from a browser. If you need authentication, you are redirected to an identity provider.

      • Support for Single Logout (SLO) SAML 2.0 flows.

      • All endpoints of your external cloud application are protected by SSL.

      • Support for SAML metadata for exchanging Federation configuration information.

      • Support for receiving and sending signed Authentication Requests.

      • Defence against XML Wrapping attacks.