Cloud Application Integration Beginner Implementation Course

1. Welcome

1.1 Welcome

Notes:

Welcome to the Cloud Application Integration, Beginner Implementation Course.

1.2 Instructions

Notes:

Hello, I’m Christy, and I’ll be your instructor for this course.
In a moment I’ll review the objectives and outline for this course.
At the end of each module, there is a quiz that you will be required to complete. This quiz is
designed to provide direct feedback on your knowledge of the content presented. You are
always welcomed to go back and review any of the information presented in any section of this
course.
Up in the right-hand corner you’ll notice a Resources area. These resources will supplement and
support this training.
To complete this training, you are required to pass the final assessment with a score of 80% or
higher.
At the end of the course, you will be presented with a survey. Your feedback is critical to the
success and further improvement of our courses. Please take a moment to complete this very
important step.
Now let’s move on to the objectives for this course.

Published by Articulate® Storyline www.articulate.com

1.3 Objectives

Notes:

Cloud Application Integration is the service in IDMC for real-time integration and process
orchestration.
The objectives of this course is to make you more familiar with the functionality within Cloud
Application Integration, to be able to deliver a successful project for a customer.
We will discuss:
· What is CAI, and what can it do to solve customers' requirements for integration
· What is a process, and what are its components
· What is a service connector, and how is it used in CAI processes
· How to access on-premise databases to read and write data.
· How to expose a process as an API for integration in external processes.
· And finally, what is Xquery, and where is it used in CAI.

1.4 Overview

Notes:

This course consists of three modules:

· CAI Overview, discussing the functionality, processes, and building blocks
· Then, you will learn to translate requirements to a CAI process based on two examples.
· In the Invoice Warehouse process, you will learn to design and build a basic CAI process
with input parameters, read web service data using a service connector and read and write
data to an MS SQL Server database.
· In the OpenLibrary process, you will learn to design and build a process reading author
and publication information from the OpenLibrary API, and transform the data into a json
output payload.

Let’s move on to our first module.

Published by Articulate® Storyline www.articulate.com

2. CAI Overview

2.1 Cloud Application Integration

Notes:

Module 1: Cloud Application Integration Overview

2.2 CAI Overview

Notes:

Cloud Application Integration will help businesses in these three main subject areas:
Real-time API and event-based integration. Integration in real-time with APIs, messaging and
publish/subscribe solutions.
Process Integration and orchestration. Automate and integrate multi-step processes that span
multiple applications on-premises and in the cloud. Automate user workflows with interactive
access to data.
API implementation and management. Expose APIs to improve business, composite and data
services. Create processes and expose as API to be used in other external software to ensure
consistency of data access and processing.
Let’s explore these subject areas in a bit more detail.

Published by Articulate® Storyline www.articulate.com

2.3 Real Time Integration

Notes:

Real-time integration addresses these two main use cases.

Front and back-office integration. For example, a direct interface between a customer-facing
web application and a back-office marketing system, to update customer contact information in
real-time.
Real-time synchronization. Think of synchronizing account information from Salesforce to
internal financial systems, synchronization of product information between various systems,
etcetera.

CAI can integrate API-based applications in real-time using APIs and messaging. CAI can be called
using an API by external applications, or it can monitor message queues to process messages
placed there.
Bulk data integration is typically batch, running at scheduled intervals. CAI can supplement this
batch integration by processing data in real time, ensuring the consuming systems always have
the most up-to-date data available.
CAI can integrate with message-oriented middleware and ESB, fitting in possibly existing
messaging infrastructure. CAI can serve both as a publisher or consumer of messages, using JMS,
MQ, Kafka, or other messaging platforms.

2.4 Process Integration and Orchestration

Notes:

Cross-Application process integration addresses business processes where multiple actions need
to be executed in different application systems to complete the process. For example,
registering a customer on a website needs to validate whether the customer meets the credit
requirements in an internal system. Only when this is approved, the customer status is set to
active and he or she is able to place orders.
Another use case is to externalize and implement business rules across applications. Having
these in CAI and exposing them as API will ensure consistent implementation and application of
the rules across the enterprise.
CAI can application and business processes from various systems into one process. This will help
to ensure the correct process flow is always followed, like the customer validation process
mentioned earlier. CAI can include so-called guides; these are screen flows where the end-user
will perform the necessary actions. These can be integrated in a workflow process.

Published by Articulate® Storyline www.articulate.com

2.5 API Management

Notes:Many applications have APIs to enable external communication. Using these API can be
complicated, due to the usage requirements and the complexity of the data structures. And,
especially when these applications reside behind a firewall, exposure to external applications
can be complicated.

CAI can be used to call external API’s to retrieve or update data in third-party applications. For
example, CAI can call Salesforce.com to retrieve or update Account or other information.
CAI can also be used to expose Api’s from internal systems to the outside world and, if
necessary, simplify the interface. For example, when updating a master record in an MDM
system, CAI can do the search to find the record, followed by the update call. The necessary
validations and transformations can all be included in the CAI process.

And finally, all exposed APIs from CAI can have security configured to prevent unauthorized
access. Also, because CAI is doing the calls to the internal systems, you can ensure that no
unexpected calls will be executed. So CAI can act as a wrapper around applications, to ensure
secure access and only allow the required actions.

2.6 Building Blocks

Notes: To build functionality in CAI, you need to understand the following building blocks:

Processes. A process is a set of steps in CAI, interacting with data and services
Process objects. These define the structure of the data
Application Connections. Connect to databases, files systems, or services
Service Connectors. Connections to third-party services using REST or SOAP API’s
Guides. A guide is a set of screens where the user can interact with the data. Guides are outside
the scope of this course
Besides these building blocks, two more essential pieces need mentioning:
Transformation functions, to transform data types, do calculations, string handling, etcetera
Xpath and xquery, to address specific fields within complex data structures
Xquery and the transformation functions are used throughout the CAI processes, but mainly in
service connectors and assignment steps.

Published by Articulate® Storyline www.articulate.com

In the following two sections, I will build and execute two processes to show how all these
components work together.

2.10 End of Module

Notes:

You have reached the end of the CAI Overview module.

When you’re ready, please proceed to the next module, Invoice Reporting.

3. Invoice Reporting

3.1 Invoice Reporting Process

Notes:

Module 2: Invoice Reporting Process

3.2 Requirements

Notes:

This is the first example of how you would approach the design and build of a CAI process.
The requirements are as follows.
The customer has a web application in which it can create invoices in a back-office application.
This application returns the invoice id to the web application.
The requirements are to store the invoice information in the customers' data warehouse within
1 minute of creation, for near real-time reporting and analysis.
The web application can also create invoices for a new customer that do not yet exist in the data
warehouse. The customer must be created first in the warehouse, before the invoice can be
stored.
The web application must receive a status message indicating whether the process was
successful.

Published by Articulate® Storyline www.articulate.com

3.3 Solution

Notes:

Based on these requirements, the process design is as follows:

The CAI process is called from the web application, which is passing the invoice number.
The process then calls the back-office system via its API to get the invoice details
Next is checking whether the customer exists in the data warehouse using a SQL query. If the
customer does not exist, create it in the data warehouse.
Then, create the invoice in the data warehouse, with the details retrieved from the back-office
application.
Based on the actions executed, return the appropriate status message.

3.4 Creating the process

Notes:

Now, let’s build this process. The 5 steps to build the process are listed below:
· Create the service connector
· Build the base process
· Lookup customer in the data warehouse
· Set output messages
· Publish the process and test.
Click on each of the steps for an explanation and to watch a demo video of the activities. A
transcript of the demo videos can be found in the resources section.

--- Create Service Connector

The first step is creating the service connector. This will contain the calls to the Invoicing web
service to retrieve the invoice and customer information.
For both these calls, the input fields, url and http action, and output fileds will be specified.
You can then test the calls from within the service connector.
You can publish the connector and the corresponding application connector when all is as
desired.
Click on the watch video button to watch these activities.

Published by Articulate® Storyline www.articulate.com

--- Create Base Process
The second step is to create the base process. Specify the input, output, and temporary fields
used. Then add the get invoice service call to get the invoice.
The next piece is to add a create step, writing the invoice data to the database.
Click on the watch video button to watch these activities.

--- Data Warehouse lookup

The third part of building the process is adding a lookup to the data warehouse to see whether
the customer exists. If not, the customer will have to be created.
The query is done in an assignment step, as you can see in the video,
If the customer is not found, it must be created in the data warehouse before the invoice can be
added. In this step, a decision step will check whether the customer exists, and if not get the
customer information from the invoicing web server and create it in the data warehouse.
Click on the watch video button to watch these activities.
--- Set output messages
As per requirement, the process must return an output message based on the process status.
You will have to set an error message when the invoice cannot be found in the invoicing system.
This will also have to stop the process.
Two more messages need to be set: one for when the customer and invoice are created, and
one when only the invoice is created because the customer already exists in the data
warehouse.
--- Test the process
The process is now ready for testing. But before you can test, you will have to set the process
execution permissions. Publish the process.
Using the “Run Using” option in CAI, you can easily test the process to verify its correct working.
Click on the watch video button to watch these activities.

Published by Articulate® Storyline www.articulate.com

3.5 Step 1: Service Connector Video

3.6 Step 2: Initial process

3.7 Step 3: Add DWH query processing

3.8 Step 4: Add error handling and status message

3.9 Step 5: Test

3.10 Summary

Notes:

The process p_Invoice_Reporting highlights some of the basic capabilities of Cloud Application
Integration. Understanding these basics will help in implementing well-designed and well-
performing processes in CAI.
In the service connector, you define the calls you want to execute towards a web service. You
also define which fields from the service you will need in your process, and where to find them
in the output payload.
You can query a database table using an assignment step. The assignment uses a query
statement to filter the data you need. You use a temporary field to assign your query result.
The decision step adds if-then-else logic in the process to allow different actions in the process
based on the condition in the decision step.
The Create step creates a row in the database table. You specify the connection and the object
you want to create.
Based on the various actions executed in the process, you set an output message, returning the
status of the process execution to the caller.
And finally, catching errors and defining alternative processing in case of errors will ensure the
process always completes in a controlled way.

Published by Articulate® Storyline www.articulate.com

3.14 End of Module

Notes:

You have reached the end of the Invoice Reporting module.

When you’re ready, please proceed to the next module, Public Library.

4. Public Library

4.1 Public Library Process

Notes:

Module 3: Public Library Process

4.2 Requirements

Notes:

A public library wants regular updates to its inventory system, triggered by purchases of new
books to add to the library.
When a new book is purchased, the worldwide book repository OpenLibrary is used to retrieve
the latest information about the author to ensure this information is up-to-date in the internal
system.
The complete list of books published by the author is retrieved to compare with the books in the
inventory.
The OpenLibrary interface differs from the API used to store data in the internal system, so the
information retrieved from OpenLibrary needs to be transformed. The required json message
must then be sent to the internal application for further processing.

Published by Articulate® Storyline www.articulate.com

4.3 Solution

Notes:

The solution design is as follows:

The CAI process is called from the internal system, where the purchase of the book is registered
initially. It passes input parameters to the process, about the author, language, and main
character.
The author name is used to call the OpenLibrary web service to retrieve the detailed author
information.
All three parameters are used to call OpenLibrary to get the list of books published by the
author.
The information returned is then parsed and transformed from the OpenLibrary format to the
json format of the internal systems APII, using a loop structure and a set of assignment steps.
And the last step is to return this information to the internal system as output message of the
CAI process.

4.4 Creating the process

Notes:

Compared to the process built in the previous chapter, this process will use a list of objects
defined in the service connector and used in a loop. It will also dynamically create an output
payload based on the number of elements in the list.
The development consists of the following steps:
- Create the service connector
- Create the base process to get the author information and book list
- Create the process structure to walk through the list and read the individual elements
- Build the output payload
- Test the process using Postman to validate the output payload.
Click on each of the steps for an explanation and to watch a demo video of the activities. A
transcript of the videos can be found in the resoucces section.
This solution can also be built following an alternative design, using process objects and a
subprocess. Click here for details of this design.

--- Create Service connector

Published by Articulate® Storyline www.articulate.com

The service connector contains three calls to the Open Library web service. The first two are
searching for the author and getting the details; the third call retrieves the list of books
published by the author. This list is kept in a so-called list of objects, referring to a process object
that will keep the book details.
Click on the watch video button to watch these activities.

--- Create Base Process

When building the base process, you define the input and output fields, and temporary fields.
Then, add the two calls for searching the author and getting the details.
The next step is to parse the three input fields to see which are populated to build the search
arguments for retrieving the books published. The service call returns the list of books, which
need to be processed.
Click on the watch video button to watch these activities.

--- List processing

There are two ways of processing a list of objects.
The demo shows how to build a loop and use list functions to process the list of objects. This is a
common structure to walk through a list and process individual elements to dynamically create
an output consisting of multiple elements within the list.
Alternatively, it can be done using a subprocess with an iteration clause; this will be shown at
the end of the demo.
Click on the watch video button to watch these activities.

--- Build output payload

The output payload is built in several steps. The first part contains the author's information as
retrieved using the calls to get the author's details. The second part contains one entry per book
in the list; this will be created in the loop process.
The final part is to close the payload to ensure the syntax is valid.
Click on the watch video button to watch these activities.

--- Test
To test the process, we will use Postman. The postman request calls the CAI process with the
input parameters, and it will show the output payload created. The “Run As” option from the
previous demo does not show the output, so Postman is the preferred tool when the process
generates a more complex output.

Published by Articulate® Storyline www.articulate.com

Click on the watch video button to watch these activities.

--- Alternative design

As mentioned earlier, you can design this process differently using process objects and a
subprocess.
The process objects define the structure of the output payload, which removes the need for the
string functions as used in the original design.
A subprocess will walk through the list of books returned from the service call and add entries to
the list of books in the output payload. This subprocess is called in the main process using an
iteration rule.
When the subprocess finishes processing the list of books, the final step is to build the output
payload from the process objects.

4.5 Step 1: Service Connector

4.6 Step 2: Initial process

4.7 Step 3: Add List processing

4.8 Step 4: Build output payload

4.9 Step 5: Test

4.10 Alternative design using Subprocess

4.11 Summary

Notes:

The OpenLibrary process showed how to work with more complex input and output.
First, the service connector configured the calls to the OpenLibrary web service. The GetBooks
call outputs a list of books, which we store in an Object List.
Using list functions like head and tail, the process reads through the list and processes the
individual elements in the list.
The jump step creates the loop in which we browse through the list.
The output payload is constructed using a set of assignments. The first assignment creates the
general author information; the assignment steps in the loop add one entry per book to the

Published by Articulate® Storyline www.articulate.com

payload. The output payload constructed must follow the json syntax, which may be difficult to
achieve with more complex payloads.
The alternative design defines the output payload as process objects. Process objects represent
the data structure to be processed or created. Using process objects will ensure the structure
complies with the json syntax.
You process the list of books from the web service using a subprocess with an iteration rule. In
the subprocess the list of books is transformed to the output payload format. The output field of
the process is a process object with its inherent structure, while in the original solution, it is just
a text string.

4.15 End of Module

Notes:You have reached the end of the Public Library module.

When you’re ready, please proceed to the course summary.

5. Summary

5.1 Course Summary

Notes:Course Summary

5.2 Summary

Notes:In this course, you have learned:

· What is CAI, and what can it do to solve customers' requirements for integration
· What is a process, and what are its components
· What is a service connector, and how is it used in CAI processes
· How to access on-premise databases to read and write data.
· How to expose a process as an API for integration in external processes.
· And finally, what is Xquery, and where is it used in CAI.
If you want to have a detailed look at the processes used in this course, you can download them
from the resources section.
When you are ready, please proceed to the final assessment for this course.

Published by Articulate® Storyline www.articulate.com