Skip to Content
Technical Articles
Author's profile photo Chase Doelling

Creating SAP C4C Integrations using Open Connectors’ Common Resources

SAP Hybris Cloud for Customer (C4C) is a cloud-hosted customer relationship management system that meets international security standards, scales up or down easily, is used in a wide variety of industries, and supports major mobile platforms. C4C’s robust Contact and Account relationship management allows for the storing Account and Contact data in a central place as opposed to distributed systems like Outlook and Mobile devices, as well as the ability to search Accounts and Contacts on various parameters, such as Account Owner, Sales Area, Sales Employee, etc, to zero in on the results that matter to you.

Of course, with so many different applications in use today, having the ability to integrate and enrich C4C with your favorite external application, like Hubspot’s inbound marketing tool, is practically a necessity in this day and age as no one application can truly do it all. But how do you do that in an easy, repeatable way?

In this blog post, we look at the complex APIs in C4C that allow for a robust Contact and Account relationship and discuss how Common Resources in Cloud Platform Open Connectors can simplify the C4C API and help create productized, reusable integrations with Hubspot or any Open Connector (i.e. external applications like Hubspot such as Microsoft Dynamics, MailChimp, etc).

 

 

 

Image 1 – The Account Collection and its relationship to other Collections in the SAP C4C API.

The image above shows the complex relationships for the Account object (also known as a collection in SAP API parlance). It is this relationship building that allows for the ability to zero in on the relevant data important to you. Let’s explore three collections: the AccountContactsCollection, the AccountContactRelationshipCollection, and the Contact Collection.

The Contact Collection allows you to create, update, delete, a contact to SAP C4C. It encapsulates the AccountContactRelationshipCollection, which in turn encapsulates the AccountContactsCollection. However, as you can see in the following snippets, the AccountContactRelationshipCollection (yellow) can be created independently of the ContactCollection. Further, the AccountContactsCollection (blue) can be created independently of both the AccountContactRelationshipCollection and the ContactCollection.

CREATE A C4C CONTACT

{
  "AccountID": "Unknown Type: string,null",
  "AccountName": "Unknown Type: string,null",
  "AccountUUID": "Unknown Type: string,null",
  "ContactID": "Unknown Type: string,null",
  "FirstName": "Unknown Type: string,null",
  "LastName": "Unknown Type: string,null",
  "ObjectID": "string",
  "ContactAttachment": [],
  "ContactBusinessAddress": [],
  "ContactCommunicationData": {
    "EMail": "Unknown Type: string,null",
    "Phone": "Unknown Type: string,null",
    "AccountContactRelationship": {
      "AccountUUID": "Unknown Type: string,null",
      "ContactUUID": "Unknown Type: string,null",
      "ObjectID": "Unknown Type: string,null",
      "AccountContactCommunicationData": {},
      "AccountContacts": {
        "ContactID": "Unknown Type: string,null",
        "ContactUUID": "Unknown Type: string,null",
        "FirstName": "Unknown Type: string,null",
        "LastName": "Unknown Type: string,null",
        "ObjectID": "Unknown Type: string,null"
      }
    }
  },
  "ContactNotes": [],
  "ContactPersonalAddress": []
}

CREATE A C4C ACCOUNTCONTACTRELATIONSHIP

{
  "AccountUUID": "Unknown Type: string,null",
  "ContactUUID": "Unknown Type: string,null",
  "ObjectID": "Unknown Type: string,null",
  "AccountContactCommunicationData": {},
  "AccountContacts": {
    "ContactID": "Unknown Type: string,null",
    "ContactUUID": "Unknown Type: string,null",
    "FirstName": "Unknown Type: string,null",
    "LastName": "Unknown Type: string,null",
    "ObjectID": "Unknown Type: string,null"
  }
}

UPDATE A C4C ACCOUNT CONTACT

{
  "ContactID": "Unknown Type: string,null",
  "ContactUUID": "Unknown Type: string,null",
  "FirstName": "Unknown Type: string,null",
  "LastName": "Unknown Type: string,null",
  "ObjectID": "Unknown Type: string,null"
}

Breaking the API down into separate objects in this way allows one to:

  • Create a Contact not attached to an account (POST /ContactCollection)
  • Relate a Contact to an Account, or multiple Accounts (POST /AccountContactRelationshipCollection)
  • Search for all Contacts that are related to a single Account and vice versa (GET /AccountContactRelationshipCollection with query parameters)
  • Retrieve all Contacts that are linked to any Account (GET /AccountContacts) or particular Contacts using query parameters
  • Retrieve the Contact information related to a relationship (GET /AccountContactRelationshipCollection/{id}/AccountContacts)

Let’s now simplify some of the above the resources to create repeatable, productized integrations using Common Resources.

 

WHAT IS A VIRTUAL DATA RESOURCE (VDR)?

A Common Resource is a resource that you create on an Open Connector with a unique name, that allows you to define the structure of the request and the response payload. Cloud Platform performs the transformation behind the scenes.

First, let’s explain what an Open Connector is. An Open Connector is much more than a simple connection – it offers:

  • Normalized SQL based query statements
  • A polling framework that is built in when the native endpoint does not offer webhooks.
  • Versioning that is managed for you – backward compatible with earlier versions
  • Normalized Authentication that is built in for both basic and OAuth flows
  • Bulk that is managed and simplified – including chucking of files
  • Always Restful JSON responses even from endpoints with native XML, etc

When you enter your credentials in an Open Connector, you create an instance.

Let’s redefine the ContactCollection and the AccountContactRelationshipCollection with Common Resources.

ORIGINAL C4C CREATE CONTACT PAYLOAD: (POST /CONTACTCOLLECTION)

{
  "AccountID": "Unknown Type: string,null",
  "AccountName": "Unknown Type: string,null",
  "AccountUUID": "Unknown Type: string,null",
  "ContactID": "Unknown Type: string,null",
  "FirstName": "Unknown Type: string,null",
  "LastName": "Unknown Type: string,null",
  "ObjectID": "string",
  "ContactAttachment": [],
  "ContactBusinessAddress": [],
  "ContactCommunicationData": {
    "EMail": "Unknown Type: string,null",
    "Phone": "Unknown Type: string,null",
    "AccountContactRelationship": {
      "AccountUUID": "Unknown Type: string,null",
      "ContactUUID": "Unknown Type: string,null",
      "ObjectID": "Unknown Type: string,null",
      "AccountContactCommunicationData": {},
      "AccountContacts": {
        "ContactID": "Unknown Type: string,null",
        "ContactUUID": "Unknown Type: string,null",
        "FirstName": "Unknown Type: string,null",
        "LastName": "Unknown Type: string,null",
        "ObjectID": "Unknown Type: string,null"
      }
    }
  },
  "ContactNotes": [],
  "ContactPersonalAddress": []
}

Common Resource PAYLOAD: POST (/MYCONTACT)

{
  "Email": "danielle@fake.com",
  "FirstName": "Danielle",
  "Id":"",
  "LastName": "Woodworth"
}

ORIGINAL C4C CREATE ACCOUNTCONTACTRELATIONSHIP PAYLOAD:

(POST /AccountContactRelationshipCollection)

{
  "AccountUUID": "Unknown Type: string,null",
  "ContactUUID": "Unknown Type: string,null",
  "ObjectID": "Unknown Type: string,null",
  "AccountContactCommunicationData": {},
  "AccountContacts": {
    "ContactID": "Unknown Type: string,null",
    "ContactUUID": "Unknown Type: string,null",
    "FirstName": "Unknown Type: string,null",
    "LastName": "Unknown Type: string,null",
    "ObjectID": "Unknown Type: string,null"
  }
}

 

COMMON RESOURCE PAYLOAD: POST (/MYCONTACTRELATIONSHIP)

{

"ContactId": "222033302232-ye44-8jss",

"AccountId": "229299933333-9r55-43ee"

}

 

Let’s also add a POST /myAccount VDR (original payload not shown)

POST (/MYACCOUNT)

{
"Name": "My Account Name",
"Id":""
}

 

Okay, so how does this help me create a productized integration with Hubspot or any other connector in the catalog?

If you also map the Hubspot Open Connector instance to the Common Resources you created above, you can now write business logic that is independent of the endpoint.

Performing a GET /accounts or a GET /contacts on the Hubspot instance will give you the raw Hubspot payload for a company and a contact, respectively. But mapping them to GET /myAccount and /myContact will give the structure you expect, and that C4C now expects (if you also POST to these Common Resources in the C4C Element Instance).

Now, you can write generic business logic either in your application or as a Formula. The calls can be made to any Open Connector instances which are set when a Formula instance is created.

Image 2 – A Formula, which consists of generic business logic made possible by the use of Common Resources. This can be reused as needed. When a Formula instance is created for a customer, that customer’s Open Connector instances are associated with this flow.

When each new customer comes along to onboard their integration, all they have to do is:

  • Create their instances by entering their credentials in the Open Connector (Hubspot, C4C, etc)
  • Map the objects (contacts, accounts, etc) to the Common Resources (including any custom fields)
  • Create a Formula Instance which reuses the business logic template (Formula) and also associates it with the customer’s specific connector instances so it knows what accounts to pull the data from.

That’s it. With nothing to deploy, creating productized integrations, to even complex endpoints like C4C, becomes a quick, repeatable process.

Assigned Tags

      Be the first to leave a comment
      You must be Logged on to comment or reply to a post.