Integrating with Salesforce using Oracle Integration Cloud

By: Courtney Dooley | Technical Architect

With all of the available integration options, it’s easy to overlook or undervalue tools that are offered to make these integrations easier.  In fact, many of these offerings are not nearly as helpful as they appear to be.  Oracle’s Integration Cloud offers a Salesforce adapter that really minimizes the development required to set up a simple integration with any other system or service.

A Simple Use Case

Salesforce Opportunities often result in a contract for products and/or services.  These contracts are often managed or produced using a contract management tool which processes approvals and renditions before the final contract is sent for customer signature.  Oracle Integration Cloud includes Process Cloud as workflow approval process engine, and tightly interacts with integrations to any number of systems and services.  Although a contract management solution can be easily built within Oracle Integration Cloud Process Applications; for this use case we will use Atlassian’s Jira on-premise service.

Jira offers a built-in REST API library that allows for easy integration to create, get, or delete issues.  For this reason, we do not need an Atlassian Jira Adapter, but can use the out-of-the-box REST API adapter.

Salesforce integrations can be triggered either by a workflow action outbound message or by simply calling the integration from a button.  For the integration to be triggered by an outbound message, the outbound message WSDL is required.  The workflow action will send not only the Opportunity ID but also other field data when triggering the integration.

For our use case, we did not have a specific set of field data that would indicate when the integration would be triggered and although custom links can trigger the outbound message, we went with the option for a button that could be used at any point in the Opportunity life cycle and is easily found alongside the other Opportunity buttons.

When triggered the integration retrieves the opportunity details, checks Jira for existing contracts issues that are linked with the Opportunity (this can be tracked within Jira or Salesforce) and based on the information the integration has acquired makes another REST API call to create a new issue in Jira or returns the existing Jira Contract information.  We could also update the existing contract with the information from the Opportunity.


Need to Know

  1. Connector Requirements

In order to create a connector in Oracle Integration Cloud Service for Salesforce, you will need an integration user to authenticate with and has access to all Opportunities within Salesforce.  You will also need access to the Salesforce environment to create an Enterprise WSDL to identify the Salesforce service you are trying to integrate with.

Once the generated WSDL is downloaded and the user credentials have been set, including appending the user security token to the end of the user’s password. The connector can be created using the Salesforce Adapter.


Oracle Integration Cloud Salesforce Adapter

 New Connection Dialog Screen

 Salesforce Connector Configuration using the Salesforce Adapter


  1. Trigger vs Invoke

Once a connector has been configured and tested, it can be used either as a Trigger (which requires the Outbound Message WSDL), Invoke or both depending on how the connector was created.  When the Salesforce connector is used within integrations, the functionality available for use is displayed in the “Action” step of the setup.


  1. Salesforce Buttons

Two ways to trigger the integration using a button are to execute JavaScript on click, or execute a URL which calls the integration.  Below is an example using the URL option and returns a JSON response including the contract URL or existing contract message.

Other Service Connections

  1. Oracle Integration Cloud out-of-the-box Adapters

AutomationAnywhere – Robot Process Automation (RPA)





Google – Calendars, Emails, and Tasks

Microsoft – Calendar, Contacts, and Emails

JD Edwards EnterpriseOne



Oracle EBS

Oracle Database

Oracle DBaaS






REST – for use with any system that has a REST API library

SOAP – for any system with a Soap API library



So as you can see, Oracle Integration Cloud offers many ways to integrate Salesforce with almost any system or service quickly and easily.  By developing simple integrations, you can eliminate the re-work of entering data into multiple systems, as well as keeping data aligned and your business in sync across all resources.


Contact us for more tips and tricks on developing Integrations using Oracle Integration Cloud!

TekStream Solutions Attains AWS Well-Architected Framework Partner Status

TekStream joins elite group of less than 150 AWS partners worldwide certified to conduct Well-Architected Framework evaluations.

TekStream Solutions, an Atlanta-based digital transformation technology firm and Advanced Consulting Partner in the Amazon Web Services Partner Network (APN), is excited to announce that they are now a part of the AWS Well-Architected Framework.

The Well-Architected Framework was developed to help cloud architects build secure, high-performing, resilient, and efficient infrastructure for their applications. Based on five pillars — operational excellence, security, reliability, performance efficiency, and cost optimization — the Framework provides a consistent approach for AWS customers and partners to evaluate architectures and implement designs that will scale over time.

Fewer than 150 of all AWS consulting partners have achieved the Well-Architected Framework (WAF) Partner designation. To qualify for the WAF Partner Program, partners must have earned Advanced Tier status, have a specified number of AWS Certified Solutions Architects on staff, and have committed to completing a minimum number of Well-Architected Reviews per quarter.

” The AWS Well-Architected Framework is the best-practice template for consistent customer cloud success. Our commitment to delivering the highest standards for digital transformation made achieving this partner designation a priority and squarely aligns with our mission and the needs of our customers.” stated Judd Robins, Executive Vice President of Sales.  “We’re very excited that TekStream is now one of the leading AWS partners approved to deliver AWS Well-Architected Reviews.”

For more information about AWS’ Well Architected Framework, visit

About TekStream Solutions

TekStream accelerates clients’ digital transformation by navigating complex technology environments with a combination of technical expertise and staffing solutions. We guide clients’ decisions, quickly implement the right technologies with the right people, and keep them running for sustainable growth.  Our battle-tested processes and methodology help companies with legacy systems get to the cloud faster, so they can be agile, reduce costs, and improve operational efficiencies. And with 100s of deployments under our belt, we can guarantee on-time and on-budget project delivery.  That’s why 97% of clients are repeat customers. For more information visit

Connecting Splunk to Lightweight Directory Access Protocol (LDAP)

By: Pete Chen | Splunk Team Lead


Splunk installation is complete. Forwarders are sending data to the indexers, search heads successfully searching the indexers. The next major step is to add central authentication to Splunk. Simply put, you log into your computer, your email, and your corporate assets with a username and password. Add Splunk to the list of tools available to you with those credentials. This also saves the time and hassle of creating user profiles for everyone who needs access to Splunk. Before embarking on this step, it’s important to develop a strategy for permissions and rights. This should answer the question, “who has access to what information?”

LDAP Basics

LDAP stands for Lightweight Directory Access Protocol. The most popular LDAP used by businesses is Microsoft’s Active Directory. The first step in working with LDAP is to determine the “base DN”. This is the name of the domain. Let’s use the domain “splunkrocks.local” as an example. In LDAP terms, it can be expressed as dc=splunkrocks,dc=local. Inside of the DN are the organizational units, OU’s. So an example of an organizational unit expressed is ou=users,dc=splunkrocks,dc=local.

Most technical services require some sort of authentication to access the information they provide. The credentials (username and password) needed to access the LDAP server is called the “BindDN”. When a connection is requested, the AD server will require a user with enough permissions to allow user and group information to be shared. In most business environments, the group managing Splunk will not be the same group managing the LDAP server. It’s best to ask for an LDAP administrator to type in the credentials during the setup process. The LDAP password is masked while it’s being typed and is hashed in the configuration file.

Keep in mind that connecting Splunk to the LDAP server doesn’t complete the task. It’s necessary to map LDAP groups to Splunk roles afterward.


LDAP: Lightweight Directory Access Protocol

AD: Active Directory

DN: Distinguished Name

DC: Domain Component

CN: Common Name

OU: Organizational Unit

SN: Surname

Sample Directory Structure

Using our sample domain, Splunkrocks Local Domain (splunkrocks.local), let’s assume an organizational unit for Splunk is created called “splunk”. Inside this OU, there are two sub-organizational units, one for users, one for groups. In Splunk terms, these are users and roles.


Group Users Users SN
User Austin Carson austin.carson
User Kim Gordon kim.gordon
User James Lawrence james.lawrence
User Wendy Moore wendy.moore
User Brad Hect brad.hect
User Tom Chu tom.chu
Power User Bruce Lin bruce.lin
Power User Catherine Lowe catherine.lowe
Power User Jeff Marlow jeff.marlow
Power User Heather Bradford heather.bradford
Power User Ben Baker ben.baker
Admin Bill Chang bill.chang
Admin Charles Smith charles.smith
Admin Candice Owens candice.owens
Admin Jennifer Cohen jennifer.cohen

Connecting Splunk to LDAP

From the main menu, go to Settings, and select Access Control.

Select Authentication Method

Select LDAP under External Authentication. Then click on Configure Splunk to use LDAP


In the LDAP Strategies page, there should not be any entries listed. At the top right corner of the page, click on New LDAP to add the Splunkrocks AD server as an LDAP source. Give the new LDAP connection a name.

The first section to configure is the LDAP Connection Settings. This section defines the LDAP server, the connection port, whether the connection is secure, and a user with permission to bind the Splunk server to the LDAP server.

The second section determines how Splunk finds the users within the AD server.

–        User base DN: Provide the path where Splunk can find the users in on the AD server.

–        User base filter: This can help reduce the number of users brought back into Splunk.

–        User name attribute: This is the attribute within the AD Server which contains the username. In most AD servers, this is “sAMAccountName”.

–        Real name attribute: This is the human-readable name. This is where “Ben Baker” is displayed” instead of “ben.baker”. In most AD servers, this is the “cn”, or Common Name.

–        Email attribute: this is the attribute in AD which contains the user’s email.

–        Group mapping attribute: If the LDAP server uses a group identifier for the users, this will be needed. It’s not required if distinguished names are used in the LDAP groups.

The second section determines how Splunk finds the groups within the AD server.

–        Group base DN: Provide the path where Splunk can find the groups in on the AD server.

–        Static group search filter: search filter to retrieve static groups.

–        Group name attribute: This is the attribute within the AD server which contains the group names. In most AD servers, this is simply “cn”, or Common Name.

–        Static member attribute: The group attribute with the group’s members contained. This is usually “member”.

The rest can be left blank for now. Click Save to continue. If all the settings are entered properly, the connection will be successful. A restart of Splunk will be necessary to enable the newly configured authentication method.  Remember, adding LDAP authentication is the first part of the process. To complete the setup, it’s also necessary to map Splunk roles to LDAP groups. Using the access and rights strategy mentioned above, create the necessary Splunk roles and LDAP groups. Then map the roles to the groups, and assign the necessary group or groups to each user. Developing this strategy and customizing roles is something we can help you do, based on your needs and best practices.

Want to learn more about connecting Splunk to LDAP? Contact us today!