This demo shows how to automate customer interactions using APIs and Integrations. To put this in a context of a business it is based on a car repair scenario. Most likely this is not an exact scenario for your client. It is up to you to make the linkage to your customer’s needs to support their customers.
All businesses have customers. Governments support citizens, B2B businesses have upstream and downstream businesses they deal with and most obviously B2C businesses have customers who need support. The demo works through a series of steps to: obtain and validate input information from a customer with a concern, open a case in Salesforce, attach the incoming information to the case, analyze the tone of the situation, and respond to the customer with the case number and expected date for resolution. This should be applicable to almost every business. Do the planning to understand your customer’s customer and what type of interactions they might have that fit this pattern.
This Demo Script has multiple tasks, that each have multiple steps. In each step you have the details about what you need to do (Actions) and what you can say delivering this demo step (Talking Points). This Demo Script is a suggestion, but you are welcome to customize based in your sales opportunity. Most importantly practice this demo in advance. If the demo seems easy for you to execute the customer will notice this. If it seems difficult for you to execute the customer will notice this as well.
0.0 - Demo Introduction
Demo Introduction | |
---|
Actions | Show Demo Introduction Slides. |
Talking Points | Automating customer interactions can provide the difference between a satisfied customer who wants to do more business with you or a disappointed customer who is looking for an alternative option. In addition, it can remove manual steps, data entry into multiple different applications, and potential errors and delays – all of which are additional costs to your business. This demo automates a series of steps to: obtain and validate input information from a customer with a concern, open a case in Salesforce, attach the incoming information to the case, analyze the tone of the situation, and respond to the customer with the case number and expected date for resolution.
To automate this customer interaction, we will use both APIs and integrations to back-end applications. The demo scenario is related to a car repair, but this is just an example. The same techniques are applicable to your environment in support of your customers.
In the demo we will execute the following steps:- Access the Cloud Pak for Integration environment and explore the capabilities
- Import and review the automated customer interactions integration flow
- Test the flow
- Deploy the flow into the Cloud Pak runtime environment
- Manage access to the flow as an API and set up the security and rate limits
- Demonstrate how a developer can use the API Portal to perform self-service consumption of the API
Let’s get started! |
Screenshots |
|
1.1 - Log in CP4I
Log in CP4I | |
---|
Actions | Open CP4I and click IBM provided credentials (admin only) and Log in with your admin user and password. |
Talking Points | As businesses execute a digital transformation, every organization seeks to move faster than before. But going fast without the right approach, guided by real-world operational data, has caused 70% of digital transformations to fail. A new approach with automation and continuous improvement fed by AI algorithms is required. IBM Cloud Pak for Integration is a hybrid integration solution that provides an automated and closed-loop lifecycle across multiple styles of enterprise integration. With IBM Cloud Pak for Integration, companies can speed integration development, reduce costs and maintain enhanced security, governance and availability. Let’s see IBM Cloud Pak for Integration in action. Here I have a cloud version of the product on IBM Cloud. Let me log in here. |
Screenshots |
|
1.2 - CP4I Home
CP4I Home | |
---|
Actions | Show the Home Page and click on Integration Capabilities. |
Talking Points | Welcome to IBM Cloud Pak for Integration! We’re now at the home screen showing all the capabilities of the pak, brought together in one place. Specialized integration capabilities —for API management, application integration, messaging and more —are built on top of powerful automation services. Let’s see the Integration Capabilities available in this Cloud Pak for Integration. |
Screenshots |
|
1.3 - Integration Capabilities
Integration Capabilities | |
---|
Actions | Show the Integration Capabilities page and open the Designer (ace-designer-demo). |
Talking Points | As you can see, through a single interface you are able to access all the integration capabilities your team needs. Including API Management, Application Integration, Enterprise Messaging, Events, and High-Speed Transfer. In this demo to automate customer interactions with our company we will use App Connect for Application Integration, API Connect for API Management, and the Asset Repository as our centralized hub for allowing our teams to work together with Integration assets. Let’s open our App Connect Designer. |
Screenshots |
|
2.1 - Create from an asset
Create from an asset | |
---|
Actions | Click Create from an Asset. |
Talking Points | Here we are in the designer tooling. This is where we can create all our API integration flows and manage our connectivity to our services and endpoints. As we begin, there is nothing here yet, so let’s build some integration logic. Let’s see how simple to create our flow from the Asset Repository. |
Screenshots |
|
2.2 - Select an asset
Select an asset | |
---|
Actions | Click on the + sign to the right on the Car Insurance Cognitive API Lab Short V2. |
Talking Points | We have a flow to use already stored in the Asset Repository, let’s use it to simplify our demonstration. |
Screenshots |
|
3.1 - Review properties
Review properties | |
---|
Actions | Show the Properties view and click on Operations |
Talking Points | The Designer builds your API for you – you don’t need to worry about OpenAPI specs or Swagger editors – it’s all built in. These are the fields we are going to use for our API. Note that we tell our API which field is the key – in our case, CaseReference. |
Screenshots |
|
3.2 - Review operations
Review operations | |
---|
Actions | Show the Operations view and click on Edit flow |
Talking Points | In the Operations view are the actions that the API exposes along with the data. In this demo, we’re going to build just one operation – “Create Car Repair Claim”. We can add more later if we wish. Let’s check the flow logic. |
Screenshots |
|
3.3 - Review the flow
Review the flow | |
---|
Actions | Initially close the Request dialog. Explain the Flow and Scroll through all of the connectors in the flow. After that, open the Request again, by clicking the first step of the flow. |
Talking Points | Here we have our demo flow. In the designer flow editor, we can edit and change our flow. We are a Car Repair company: We take in vehicles with problems and repair them. We want to create an API which enables customers to send us photos of their cars along with descriptions of what needs to be done. With this information, we will create a case in Salesforce and use Watson to analyze if the customer is angry or upset. Let’s explore our flow in detail. |
Screenshots |
|
3.4 - Review Request
Review Request | |
---|
Actions | Show the Request dialog (1). Click to open the if step (2). |
Talking Points | Our flow starts by receiving the customer’s car repair request with photo via an API. Designer automatically creates an API “Request” and “Response” for your API flow. |
Screenshots |
|
3.5 - Checking the Photo
Checking the Photo | |
---|
Actions | Explore the if step (1) and click on Salesforce Connector - Retrieve contacts (2). |
Talking Points | Second, we validate the photo. Here, we have a simple if statement, that check if the PhotoOfCar is empty. If it is not empty, we move forward to retrieve contacts by connecting to Salesforce. |
Screenshots |
|
3.6 - Retrieve contacts
Retrieve contacts | |
---|
Actions | Explore the Salesforce Connector - Retrieve contacts (1). Change the Contact name to Andrew Young (2). And test the connection (3). Change back the Contact Full name to Andy Young (4) and test again (5). Open View details (6). On the Output, open the Contact1 object (7). Close all the dialog tabs. Click on the Salesforce – Create case node (8). |
Talking Points | Third, we use a connector to create a case in Salesforce with the data from the API. This Case is where we store the details and progress of our repair. We are using a hard-coded contact name: ‘Andy Young’. He’s the contact for the insurance company that sends customers. Salesforce Developer Accounts have a prepopulated set of data that you can use to test. ‘Andy Young’ is one of those prepopulated contacts. Let’s test our connection with Salesforce. Let me change the contact to Andrew Young, and test the connection. The test shows that we don’t have an Andrew Young. Let’s change it back to Andy Young and test again. Now we received a successful response. This proves that our connection is working. Let’s check the details. Here we can see the output returned from SalesForce, including the Contact ID. |
Screenshots |
|
3.7 - Create Case
Create Case | |
---|
Actions | Explore the Salesforce – Create case node. Close the Salesforce connector dialog. Open the Salesforce - Create Attachment node. |
Talking Points | Now we have the ID that we need, let’s create our Salesforce case. Note that we just re-use the same Salesforce connector but with a different operation and data. Here we can see that our contact ID comes from the previous ‘retrieve contact’ Salesforce Call. The Name and email come from the API Request. The connector ‘knows’ that fields like ‘Case Type’ have a limited number of values in Salesforce – so it automatically converts them into pull-down lists of values you can choose. |
Screenshots |
|
3.8 - Create Attachment
Create Attachment | |
---|
Actions | Explore the Salesforce – Create Attachment node (1). Close the Salesforce connector dialog. Open the IBM Watson Tone Analyzer node (2). |
Talking Points | To add a photograph, we need to create a salesforce attachment – that’s easy, just use the connector again. Note that we use the Case ID that is a returned value from the ‘Create Case’ connector call – it’s been kept in the flow automatically. We send the PhotoOfCar as a base64 string and we tell Salesforce that the content Type is image/jpeg. Moving forward to the next step we want to understand the tone of the request. Is the customer angry? We will use the IBM Watson Tone Analyzer node to understand the situation better. |
Screenshots |
|
3.9 - Analyze the description
Analyze the description | |
---|
Actions | Explore the Watson Tone Analyzer connector (1). Close the Tone Analyzer connector dialog. Open the Salesforce - Create case comment (2). |
Talking Points | Here, the Watson Tone Analyzer service analyzes the description shared by the customer, to identify if the customer is angry or upset, that demands further action or the need to treat them more carefully. |
Screenshots |
|
3.10 - Create case comment
Create case comment | |
---|
Actions | Explore the Salesforce – Create case comment node (1). Close the Salesforce connector dialog. Open the Response. (2) |
Talking Points | Then we’ll add a comment to the case with the Salesforce connector and supply the tone name returned from Watson into the body of the comment. |
Screenshots |
|
3.11 - Response
Response | |
---|
Actions | Explore the Response dialog (1). Click Done (2). |
Talking Points | Here, we have the response that we submit back to the customer after the API call. This response includes their Salesforce case reference for future enquiries and also an estimate of how long it will take to repair and how much it will cost. Great. we’ve built the flow, let’s start it! |
Screenshots |
|
4.1 - Starting the Flow
Starting the Flow | |
---|
Actions | Click Start API on the three dot menu at the top right |
Talking Points | Now we’ve looked at the integration flow, let’s start it up. Great! Now our flow is running, we need to test it. |
Screenshots |
|
4.2 - Setting Environment Variables
Setting Environment Variables | |
---|
Actions | Open the Test tab (1). Copy the Endpoint URL (2). Open POST /CarRepairClaim (3). Open Try it (4). Copy the Username (5) and Password (6). In your script folder, on terminal window, edit the 00-variables file (e.g.: vi 00-variables) and update the BASEPATH (7), USERNAME (8) and PASSWORD (9). Execute source exportVariables.sh (10) |
Talking Points | Now we’ve built our API, we need to test it. APIs can be tested in various ways. During this demo, we will do 3 different tests, one in the designer tool - now, another when our API is deployed to the Cloud Pak App Connect Runtime. And the last test, will be calling thru a Gateway. For simplicity and speed, as we’re using base64 pictures, we will use simple curl scripts so that we can call the APIs from the command line. Before we execute the script to call our API, we need to configure our script to point to our environment. To get the credentials for the designer, we go to the ‘Manage’ tab in designer. Now, let’s change our variable files to use these credentials. Great, let’s export now these variables. |
Screenshots |
|
4.3 - Running the Test
Running the Test | |
---|
Actions | Edit the demotestcar.sh script (1). Explore and close the file. Execute ./demotestcar.sh (2). |
Talking Points | Now, it is time to run the script. Let’s check the script. Here we can see that we have a simple curl command that call our API, passing the user and password. And our data request, is JSON with all the information about the case, including a picture with a Subaru SUV. It is ready. Let’s run this script. Great, we received the expected response with the case information. |
Screenshots |
|
4.4 - Checking Salesforce
Checking Salesforce | |
---|
Actions | Open the Salesforce Dev Account site (1). On the App Launcher menu, search for cases (2). Open the Cases page (3). On Cases view, open the latest Car Breakdown case (4). Explore all fields, including picture and Watson analysis (5). |
Talking Points | Let’s see our Salesforce system, to check if we have a new case. Let’s open the Cases page. And in the Recently Viewed, we can check all open cases. Here we have our case with all the information, including the picture, and the Watson tone analysis. With this information, our Customer Relationship team can work to support our customer. |
Screenshots |
|
5.1 - Export the BAR File
Export the BAR File | |
---|
Actions | Into the Designer Dashboard (1), click the menu (2) and click Export (3). Select Runtime flow asset (BAR) (4) and click Export (5). |
Talking Points | To deploy the flow to an integration server, you must export it as a BAR file. All the configuration settings, other than the connection credentials for your accounts, are preserved in the exported archive. Let’s export an executable BAR file. From the dashboard, locate the flow, open its menu, and then click Export. When you export a flow, you can choose to export its configuration as a YAML or BAR file, or as an OpenAPI document. In our case, we export as a BAR File. |
Screenshots |
|
5.2 - Import the BAR File
Import the BAR File | |
---|
Actions | Open the Main Menu (1), and click Run > Integrations (2). Click Create a server (3). Select Quick start designer integration (4) and click Next (5). Upload the BAR file (6) and click Next (7). Select ace-designerdemo-designer-acc (8) and click Next (9). Enter a name for our integration server (10). Set Enable Operations Dashboard tracing to On (11). Enter cp4i as *Operations Dashboard namespace (12). Click Create (13) |
Talking Points | Now, let’s open the App Connect Dashboard and create a new server. We need to create an integration server to run our integration. An integration server is a Kubernetes pod which has the containers needed to run our BAR file. We need to select the kind of tooling we used to build the integration. We used the Designer. So, we just need to upload the BAR file that we exported from designer. And here we choose which configurations we want. Here we enter the information that we want for our Integration server. Great, let’s create it! |
Screenshots |
|
5.3 - Verify the Server
Verify the Server | |
---|
Actions | Click on our Integration Server (1). Open our API Flow (2). Explore the API detais (3). |
Talking Points | Now we have our new Integration server. We need to wait some time for the pods to start. At this point, the integration is running on the Cloud Pak. Opening the server, we can see our API Flow. And click again, we’ll drill down further and see our API details. We can see the REST Operation, the base URL, and we can even download the OpenAPI document. |
Screenshots |
|
5.4 - Testing the Flow on the Runtime
Testing the Flow on the Runtime | |
---|
Actions | Copy the Endpoint (1). In your script folder, on terminal window, edit the 00-variables file and update the BASEPATH (2). NOTE:remove the ”/” from the end of the endpoint. Execute source exportVariables.sh (3). Execute ./demotestcar.sh (4). Check the new case in Salesforce (5). |
Talking Points | We’ll use the same scripts we used to test designer – we’ll just change the variables to point to the CP4I runtime. In the Server, we can get the runtime information. Let’s update our variables file and export them again. Now, we just need to run our script again with the same request data. Great, we can check the Salesforce cases page, and voilá here we have our new case created by calling the API in the Integration Runtime. |
Screenshots |
|
6.1 - Download OpenAPI Document
Download OpenAPI Document | |
---|
Actions | Click Download OpenAPI Document link (1). Open your YAML file with any editor and manually add x-ibm-configuration: gateway: datapower-api-gateway (2). |
Talking Points | We’ve created an application integration flow and successfully called it via a REST API call! Now, to make it accessible to the rest of the world, it’s important to add security around it. Let’s export our API to API Connect by downloading the OpenAPI Document. |
Screenshots |
|
6.2 - Develop API
Develop API | |
---|
Actions | Open the Menu (1) and on Run (2) section, select APIs (3). If necessary, select the ademo instance (4). In the API Connect page, click Common Services user registry (5). Click Develop APIs and Products (6). Click Add, then choose API (from REST, GraphQL or SOAP) from the drop-down menu (7). Choose From an existing OpenAPI service (8) and click Next (9). Upload our Car_Insurance.. YAML file (10) and click Next (11). Confirm the Info about API and click Next (12). Keep the security settings and click Next (13). |
Talking Points | Now, let’s open our API Manager. Here, we add our API from an existing OpenAPI service by selecting our YAML file. We just confirm the info about the API. And keep the security settings. Great our API with Client ID is created! |
Screenshots |
|
6.3 - Edit API
Edit API | |
---|
Actions | Click Edit API (1). Change to Online (2). scroll down to Base Path. You’ll see the base path has a trailing slash, at the |
end, remove this (3). Click Save (4). Click Test (5). | |
Talking Points | Let’s check our new API in API Manager. We will put our API online and test it. |
Screenshots |
|
6.4 - Test API
Test API | |
---|
Actions | Copy the POST URL (remove /CarRepairClaim) (1). Copy the X-IBM-Client-Id (2). In your script folder, on terminal window, edit the 00-variables file and update the BASEPATH and CLIENTID (3). Execute source exportVariables.sh (4). Execute ./demotestcar.sh (5). Check the new case in Salesforce. |
Talking Points | We can use this page to test the API, but we will need to include the JSON body. Let’s use the test script, that is ready. We just need to copy the new URL and the Client ID and update our script variables. |
Screenshots |
|
6.5 - Publish API
Publish API | |
---|
Actions | Open the Menu (1) and click Publish (2). Enter Car Repair APIs as Product Title (3). Select Catalog for Demo use (ddd-demo-test-catalog) and click Publish (4). |
Talking Points | We will make the API available to developers. To do so, the API must be included into an API product and then published to the catalog. A product dictates rate limits and API throttling. |
Screenshots |
|
6.6 - Adding a Rate Limiting Plan
Rate Limiting Plan | |
---|
Actions | Open the Products tab (1). Click on the Car Repair APIs product (2). Click on Plans (3). Click Add (4). Enter Gold Plan as Title (5). Change the Rate Limits to 100 Calls Per 1 minute (6). Click Save (7). Open the Develop page (8). Back to the Products tab (9). Open the Menu and Publish the Product (10). Select the Catalog for Demo use (11). Click Publish (12). Open the Manage (13), open the Catalog for Demo use (14) and check the Products state and plans (15). |
Talking Points | Security is applied to APIs. Rate limiting is applied to either APIs or API products. Let’s assign a rate limit for the API Product. We just need to open our new product. Rate Limiting is accomplished using plans. Let’s create a new Gold Plan with a specific Rate Limits. Great we have now two plans, the Gold and the default plan. We can have multiple plans for different consumers, for example we can add approval steps for consumers when they sign up or we can allocate them plans as a provider. Ok, now we need to republish our product. You’ll be prompted for a catalog to publish to. We only have one gateway installed so we don’t need to worry about that. Just Publish. |
Screenshots |
|
7.1 - Accessing Portal
Accessing Portal | |
---|
Actions | Open the Catalog settings (1). Click Portal (2). Copy the Portal URL (3). Open a new Browser tab and access the Portal URL. If you don’t have a developer account click Create account to create it (4). As soon as you complete the registration (5), just Sign in (6). |
Talking Points | Now that we’ve published our API, we need to make sure that our API consumers can discover it and use it. Our Portal allows potential API consumers to view the APIs, sign up and subscribe to plans in a self-service manner, test the APIs, download the OpenAPI - Swagger documents and more. Let’s get our portal URL and sign up as a Consumer of our API using Portal Self-Service. |
Screenshots |
|
7.2 - Create a new App
Create a new App | |
---|
Actions | Click Create a new App (1). Enter Car Repair Application as App Title (2). Click Save (3). On the credentials dialog, click OK (4). On the Subscription tab, copy the Client ID (5). |
Talking Points | As a Consumer/Developer, we’re going to create a new application in the Portal. This will give us an API key so we can call our APIs. We just need to give an Application Title and copy the API Key and Secret. |
Screenshots |
|
7.3 - Subscribe to API
Subscribe to API | |
---|
Actions | Click Why not browser the available APIs? (1). Click Car Repair APIs 1.0.0 (2). On Gold Plan, click Subscribe (3). Select the Car Repair Application (4). Confirm the Subscription by clicking Next (5). Click Done (6). |
Talking Points | We’ve not subscribed to any APIs, let’s do it now. There’s only one API Product to subscribe to in our demo – normally there would be many. Now that we selected our API product, we can see the plans available. You’ll need to hover over to get the limits – we want the gold plan. We want to subscribe to the plan – but which application do we want to use to subscribe? We can have many applications but, in this demo, we’ve only created one. So, we just need to select the App that we created earlier and confirm our subscription. And Done - we are subscribed to our API! |
Screenshots |
|
7.4 - Test API
Test API | |
---|
Actions | Click on the Car_Insurance API itself (1). Copy the Endpoint (2). Open the POST /CarRepairClaim (3). Explore the Example request area (4). Open the Try it tab (5). Click Generate (6). Click Send (7). Explore the Response (8). |
Talking Points | We’re now back at the product screen. Let’s explore our API here. From the Overview page, we can download the OpenAPI Document and get the API Endpoint. Note the portal has everything you need to call your API, it’s even generated clients in various languages for you to copy/paste into your calling application. You can try the API on the Try it area. Using the Generate button, the portal generates a request with random sample data for you. Now, let’s test it. Great, we got a response, our API is running, and we’ve gone through the gateway to access it. |
Screenshots |
|
7.5 - Viewing the API Statistics
Viewing the API Statistics | |
---|
Actions | Click Apps on top menu (1). Click the Car Repair APIs (2). Explore the API stats (3). |
Talking Points | We can see our API statistics in the Portal. We just need to select our APP, and here we can see all the API calls, including any possible errors. If you make more calls, you’ll see larger statistic results. |
Screenshots |
|
8.0 - Demo Summary
Demo Summary | |
---|
Actions | Show Demo Final Slides. |
Talking Points | Let’s summarize what we’ve done today. In the demo we:
- Accessed the Cloud Pak for Integration environment and explored the capabilities
- Imported and reviewed the automated customer interactions integration flow
- Tested the flow
- Deployed the flow into the Cloud Pak runtime environment
- Managed access to the flow as an API and set up the security and rate limits
- Demonstrated how a developer can use the API Portal to perform self-service consumption of the API
From a business perspective we used APIs and application integrations to automate a series of steps to: obtain and validate input information from a customer with a concern, open a case in Salesforce, attach the incoming information to the case, analyze the tone of the situation, and respond to the customer with the case number and expected date for resolution.
The customer expressing a concern or needing assistance obtains rapid response to their interaction and the confidence that your business is handling their request. |
Screenshots |
|