Welcome to Developer 3

2
Accessing the Platform

https://platform.boomi.com

17
 • Process Route

Course • Shared Web Server and Event-based

Integration
Overview • API Management

• Best Practices

20
 Process Route

21
What is the Process Route?

• Dynamically choose a subprocess to execute at runtime based upon a

document value
• Reduces configuration and maintenance when building processes handling
many different document types and execution paths
• What makes Process Route different from a Process Call?
• Ability to dynamically determine which subprocesses to execute based on some runtime
criteria
• Ability to deploy the main and subprocesses independently

22
Process Route Considerations

• References are based on a value, such as a document property, data profile,

or extension value. Multiple conditions and values in the Process Route
shape allow for different execution paths.
• The subprocess a Process Route calls are not statically defined at build time.
• Processes containing Process Route components, cannot be:
• Published to the process library
• Made available to managed accounts as part of an integration pack
• Deployed as a unit via the API

23
Process Route Deployment

• The parent process, Process Route component and all subprocesses must
be deployed independently.
• Independent deployment allows you to create a new or change an existing
subprocess without redeploying the parent process or any other subprocess.
• Independent deployment also means you must remember to deploy the
Process Route component and any affected subprocesses each time they
are updated.

24
Process Route Deployment (continued)

• To modify a subprocess called by a process route, redeploy only the

subprocess.
• To add a new route and subprocess to the process route:
– Create and deploy the new subprocess
– Update and redeploy the Process Route component
• To change common logic in the parent process (such as error handling),
modify and redeploy only the parent process.

25
Creating a Process Route Component

• Create and name the

component on the Build tab.
• General Configuration:
– Subprocess Options:
Passthrough
– Configure Return Paths: Path
Name

26
Creating a Process Route Component

• Create and name the

component on the Build tab.
• General Configuration:
– Subprocess Options:
Passthrough
– Configure Return Paths: Path
Name

• Process Routing:
– Keys: Route Key, Route to
Process
– Return Path Mapping

27
Creating a Process Route shape

• Route by Process Route

• Route by Processing Group
• Define Options and Return
Path Execution Sequence

28
Creating a Process Route shape

• Route by Process Route

• Route by Processing Group
• Define Options and Return
Path Execution Sequence
• Route Parameters

29
Deploying a Process Route Component

• Deploy the main process

• Deploy all subprocesses
referenced in the Process
Route
• Switch the Component
type list from Processes
to Process Routes
• Deploy the Process Route
component

30
Understanding Process Route’s Execution Behavior

• Documents are routed to a single path only. Duplicate and wildcard keys are
not allowed, so documents cannot match to multiple paths.
• Documents are grouped by Route Key, and then each group is sent to the
respective subprocess.
• Return Paths are executed in the sequence defined within the Process
Route shape, not the component.
• The Default path for documents not matching a Route Key are executed last.
• Process Route subprocess executions behave the same as regular Process
Call executions with respect to:
• Process Reporting
• Execution “context”

31
To Learn More about Process Route
• Visit the Dell Boomi Community
• Click on Knowledge Center
• Read the Article “How to use the Process Route shape and component”

33
 Shared Web Server
Event-Based Integration

34
What is Event-based Integration?

• Based on Service Oriented Architecture (SOA)

• Event-based integrations occur in response to irregularly occurring external
events. Typically, event-based integration processes are not executed on a
schedule. Instead, once executed, an event-based process continuously
“listens” for the occurrence of a specific event. The occurrence of the event
triggers processing.
• Web service publishing is one part of this. AtomSphere can help you
accomplish your web service publishing needs. AtomSphere will act as the
web service tool between any multitude of systems.
• Supported Web Service Options:
• Rest API
• SOAP API
• HTTPS
• WSDL Publishing
35
What capabilities does AtomSphere have?

• Works with multiple process requirements

– Small
– Frequent
– High Volume
• Ability to be a web service or publish a WSDL
• Can process event based solutions
• Can act as an embedded Web Server

36
How does AtomSphere fit in?

37
Support for Event-based Integration

• Real-time and HTTP status Dashboards

- Web based interface for process management
• Low latency
- Process option for increased execution speed
• Atom Worker
- Dedicated to processing live event requests

38
Real-time Dashboard
• Monitor Real-time processes
• Gauge response times
• Reports successful processes with Low Latency enabled

39
HTTP Status Dashboard
• Logs are not available in Process Reporting or the Real-time Dashboard
• Codes are standard HTTP status codes
• Page is divided into two sections (“gadgets”), displaying Status Code Summary and Status
Codes by time

40
Low Latency Process Option
• Request or response data is
not recorded
• Process metrics are not
recorded in the View Process
State dialog, but the process
log is available
• The inbound data’s document
logs are disabled

41
Low Latency and an Atom Worker
• The first request that causes an • If you are using an Atom worker on
Atom worker to start can cause the Dell Boomi Atom Cloud, the
some delay in execution time. following limitations apply:
• Atom workers shut down • The maximum number of Atom
processes that can execute
automatically after 24 hours. A simultaneously is 20 (with 10
new one starts upon the next queued).
request. • For Low Latency mode requests
• When Atom workers are running on an Atom worker, the
maximum Atom process execution
enabled for an account, it time is 30 seconds.
applies to all low latency HTTP
listener processes on the Atom
Cloud.

42
Web Services Server Connector

The Web Service Server Connector allows Dell Boomi customers to turn any
integration process into a web service that can then be deployed on premise or
in the Dell Boomi Atom Cloud. Web services deployed in the Atom Cloud can
be dynamically invoked by any cloud or on-premise application through
connect.boomi.com. All web services, whether deployed on premise or in the
cloud, are managed from one central location in Dell Boomi AtomSphere to
help extend and strengthen existing governance policies.

43
Web Services Server Features
• Asynchronous
• No response
• Synchronous API
• Response Specs
Login
• Single SOAP Credentials
• Single XML at a time
• Multi SOAP
• Multiple XML at a time
• RESTful
• Data contained in URL
• Trigger
• Used to trigger a process outside of Boomi

44
Shared Web Server Settings and Configuration
• Shared server settings
controlled at the
Atom/Molecule/Cloud level and
determine what type of requests
can be made
• API Type is Intermediate when
using the Web Services Server
Operation
• Only specific users can hit the
API
• Available endpoints are
/ws/simple/ and /ws/soap/
• Under User Management,
Users can be added,
Passwords generated, and
Process Filtering enabled

45
To Learn More about Web Service Features
• Visit the Dell Boomi Community
• Click on Knowledge Center
• Watch “Getting Started: Introduction to Publishing Web Services”
• Install and review Web Services Publishing Basics Examples from the Process Library

46
 Walkthrough:

Check configuration of Production

and Test environments

Walkthrough

Page(s): 4-6

48
Business Use Case for Activity
• Users enter contact information into an online form
• The application sends the information to the Dell Boomi Web Server
• AtomSphere processes and validates that information and returns the appropriate responses
• Contact information is sent via email to the appropriate team member

49
Web Services Integration Activity
• Create a new Operation in the Web Services Server Connector to ‘Create Contact’
• Configure the Decision shape and Mail Operation, then add a Return Documents shape
• Deploy the process
• Configure the Web Service Client to call the listener process
• Call the process, and confirm results

50
 Participants to Complete:

Web Services Integration Activity

Participants
to Complete

Page(s): 7-16

51
 Instructor To Demonstrate:

Web Services Integration Activity

Instructor to
Demonstrate

Page(s): 7-16

52
 API Management

54
What is API Management?

• The main purpose of the API Management feature is to enable a web service
publisher to expose versioned APIs for logical groups of web services. This
web service API consists of a set of REST and/or SOAP endpoints.
• This allows for web service components to be consolidated into a single,
explicit location, making API design easier and more efficient.
• Rather than having multiple listeners at different addresses, API Management
can organize each operation into one WSDL, that can be easily consumed by
customers and/or partners.

55
How Boomi API Management Works

Create 1 Configure APIs through a web-based, visual

experience

Publish 2 Deploy APIs with comprehensive security and

authentication

Manage 3 Monitor your APIs through traffic control and

usage dashboards

56
Boomi API Management

Create 1 Configure APIs through a visual experience

• Prototype with APIs and adapt to

new business requests
• Iterate with existing integrations
and version control
• Transform and enrich data with
SOAP, REST, or OData-based APIs

57
Boomi API Management

Publish 2 Deploy APIs with comprehensive security

and authentication

• Expose valuable data anywhere

with integration and web
services
• Protect your data and grant
access with custom roles and
permissions
• Control and govern data with
authentication and policy
management

58
Boomi API Management

Manage 3 Monitor your APIs through traffic control

and usage dashboards

• Discover and engage with APIs

from the catalog
• Access documentation with
tutorials and reference guides
• Measure relative health of your
APIs with usage dashboard

59
Web Services Server vs. the API Component

The Web Services Server Connector

• The Web Services Server connector is a listen-only connector that accepts

SOAP and simple HTTP requests in real time and initiates AtomSphere
processes.
• Deploying a process that contains a Web Services Server connector to an
atom will launch the web service and web server that will listen for requests
or documents.
• This is the simplest/default method of deploying a web service and can be
used stand-alone without using the API component.

60
Web Services Server vs. the API Component

The API Component

• Advanced web service API management is an optional feature for enabling a

web service publisher to expose versioned APIs for logical groups of web
services in keeping with SOA best practices.
• It provides more flexibility and more capability. You can build more robust
web services beyond just using the Web Services Server connector.
• In this context, a web service API consists of a set of REST and/or SOAP
endpoints. The different endpoints become unique/organized APIs that are
implemented in AtomSphere in the Build tab as separate components and
are then deployable as web service components. It is essentially a way of
making more endpoints beyond just ws/soap or ws/simple (e.g., unique
request URLs).

61
Web Services Server vs. the API Component

The API Component (continued)

• You can customize the web service component’s SOAP or REST API to have
unique service names and namespaces
• Once built, a web service component can be attached and deployed to
Atoms or environments in the Deploy page in the same manner as process
components.
• AtomSphere automatically generates a WSDL for each deployed SOAP API.
• Each endpoint must have an independently deployed linked process that
uses a Web Services Server connector operation to listen for and act upon
web service requests.
• When you use the API Component, you will also use the Web Service Server
Connector.
62
Primary Components Used

Return Documents shape

Placed at the end of the Web
Services Server process,
Web Services Server which will return the
Connector documents back to the
Acts as a listen-only customer or partner as the
connector that acts as the response.
process to be executed. Can
accept REST, SOAP and
simple HTTP Requests API Component
(simple is not available when Organizes and exposes the
using the Web Service REST, SOAP and OData
component). endpoints. Also allows
exposing different sets of
endpoints for different
customers or partners.

63
API Component Configuration
• The API Component is a reusable component housed in the Component Explorer
• The General settings tab includes published metadata, which is exposed upon deployment
• Two configurable options: Base API Path and HTTP Headers

64
Import Endpoints into the Web Service
• Endpoints can be imported into the API Component
• Click ‘Import an Endpoint’
• Select: Create a New Process, Import from an external service, Use an existing process, or
Import processes from environment

65
REST, SOAP, and OData Tabs
• The API component also contains REST, SOAP, and OData tabs.
• To edit a REST endpoint, click on the settings wheel below Actions and select edit endpoint

66
REST, SOAP, and OData Tabs
• The SOAP tab is similar to the REST, but does not contain as much configuration.

67
Profiles Tab
• The Profiles Tab contains information regarding the input and output profiles that are defined.

• Profile standardization issues may be present here. For example, if you had two different
profiles that used the same namespace or no namespace (but the same root element), you
would need to standardize one profile (or change it) so the API would be able to recognize
which profile to use with the Input and Output.

68
Population of Meta (Published) Information

• The Published Information tab contains the information that is provided with the WSDL, which
is published when you deploy the Web Service.

69
Shared Server Settings

• Shared Server Settings are

controlled at the
Atom/Molecule/Cloud level, and
determine what type of requests can
be made.
• There are 3 Web Service Types:
Basic, Intermediate, Advanced
• When using API Management,
‘Advanced’ is required.
• If developing without API
Management, but the Web Service
component may be used in the
future, use /ws/soap/ endpoints, as
/ws/simple/ is disabled when using
‘Advanced’.

70
Web Service Types
Basic
Primary use: When integrating “Web Services Server Operation”
component (Listeners), and anyone can hit the API (or with a specific
token that is not user specific).
Available Endpoints: /ws/simple/ and /ws/soap/

Intermediate
Primary use: When integrating “Web Services Server Operation”
component (Listeners), and only specific users can hit the API.
Available Endpoints: /ws/simple/ and /ws/soap/

Advanced
Primary use: When integrating “Web Service” component.
Available Endpoints: /ws/soap/ and /ws/rest/

71
Support for API Management
• API Management view includes the API Management Dashboard

72
Support for API Management
• API Management view includes a list of all APIs in your account

73
Support for API Management
• API Management view includes a list of any Authentication Brokers or Sources you have
configured

74
Support for API Management
• Any Applications you have created and authorized are shown under API Management view.

75
Support for API Management
• API Management view includes an API Catalog, includes access to a Swagger Visualization
Portal (click the Version Name of the API to open a detailed view window)

76
Support for API Management
• Access the API Management User Guide (from within AtomSphere User Guide) to learn more
about features and configuration

77
API Management Activity
• Load two processes from the Process Library
• Create and configure the API Component
• Deploy the listener processes and the Web Service
• EXTRA Step—Test the API!

79
 Participants to Complete:

API Management Activity

Participants
to Complete

Page(s): 17-25

80
 Instructor To Demonstrate:

API Management Activity

Instructor to
Demonstrate

Page(s): 17-25

81
AtomSphere Implementation
Best Practices

82
 Best Development
Practices Framework

83
 1. Design Guidelines

84
Design Guidelines

1. Use native Boomi functionality when possible. Avoid Java/Groovy unless it

is the only option.
2. Use common framework components when possible.
3. Utilize common re-usable processes as sub-processes in your design.
4. Enable connector level extensions in every process.
5. Utilize tracked fields for unique document identifiers when possible.
6. Utilize label fields in components and description fields in processes.

85
Design Guidelines

Establish Folder Structure Guidelines

Establish Component Naming Guidelines:
Process Name ex: [source system] + function + type of data
+ action performed [destination system]
SF Update Employee Records OEB

86
Design Guidelines

Establish Labeling Guidelines:

• Determining document flow in the process logs will be more clearly
defined.
• Documenting processes will be easier by defining what each component
does based on the label.
• The description field in the process should be utilized to define an overall
description of the integration process. Also, if an internal documentation
system (such as a Wiki) is being utilized for documenting the integration
process, a link to the documentation should be included within the
description field.

87
Process Development Checklist
• Are all shapes/steps connected?
• There should be no red connector endpoints.
• Are the appropriate connector(s) assigned?
• Make sure there are no BROWSING ONLY connectors assigned.
• Have the extensions been enabled in the process?
• Verify that the correct connector fields have been extended.
• Verify the appropriate process properties/dynamic process properties have
been extended.
• Have the shapes/steps been properly labeled?
• Have the correct Process Options been set?
• Purge data immediately should be set for any processes that contain
sensitive data.
• Are error handling shapes/steps configured?
• Has the process been successfully unit tested?
• Were the design guidelines followed?
88
 2. Accountability

89
Accountability
• Document tracking feature should be used.
• Implement appropriate error handling, notification, and logging.
• Use appropriate file names (when using disk or ftp connector).
• When possible, pass internal keys from the source system to a field in
the destination system. Optionally, you may also want to write keys from
the destination system back to a field in the source system.
• In most cases, going directly to a Stop shape from a Route, Decision,
Try/Catch, or Business Rules is discouraged. If any documents go
down this branch, it will be difficult to trace after the execution is
finished.
• Terminate your branches with Stop shapes, even if it will not change the
results of the process. This will communicate your intentions as the
developer to whomever may need to maintain your process in the
90
future.
 3. Maintainability

91
Maintainability
• Proper folder structure
• Sensible process layout
• Use of the notes feature encouraged
• Use of sub-processes where appropriate
• Should not filter on minus ‘n’ days in Connector Call
• Eliminate redundant copies of components, especially Connections
• Ideally, use a single Connection component per endpoint for
deployment (and possibly 1 more for browsing). For example, a single
component for SalesForce. Use environments/extensions to point it to
sandbox/QA/production instances

92
Maintainability
• Keep components out of the root folder. For small accounts, putting
shared Connections in the root folder is acceptable.
• Avoid using personal logins for endpoints. For example, configure your
SalesForce connection to use BoomiIntegration rather than JoeSmith.
• Use shared components where appropriate. Keep shared components
together in a shared folder.

93
Naming Conventions
• Shape labels
• use labels for Set Properties, Data Process, and Decisions
• optional for Branch and Route
• generally discouraged from labeling Start shape, Maps (unnecessary
with good component naming), and Stop shape
• Component names
• All components should have names (not “New Map” or “New Profile”)
• Rename any components that have had a numeric suffix added by
Boomi to enforce uniqueness. Avoid putting indicators such as
“production” or “test” in your component name if you are using
environments/extensions
• Folder names
94
Ideally, Have Only a Single Copy of Your Process
• “Test copies” of your processes are discouraged.
• Changes are normally done in your single process, unit tested in test
mode, deployed to a test or QA environment for further testing, then
promoted to production.
• If you are planning extensive changes to a process, a v2 of your
process is acceptable.
• A backup copy of a folder is acceptable only if done infrequently;
consider copying to another Boomi account if one is available.

95
 4. General

96
General
• Appropriate use of Options in the build tab. For example, do you want to
allow simultaneous executions? Is your listener process set to Low
Latency?
• Process should be designed to be re-runnable (for example, should
handle Upserts rather than just Creates). This helps when re-running a
process after a partially failed execution.
• Date handling in Maps. Where possible, define as true date in both
profiles, and avoid the “date convert” function .
• Decoupling process flow when appropriate (e.g., JMS or atom queues).
• The Business Rules shape is preferable to a group of Decision shapes.

97
General
• Multiple Disk Connection components should be avoided. Directories
can be specified in a Set Properties shape or Connector Parameters
tab.
• If possible, use sync flags to select source data instead of using
lastSuccessfulRunDate.
• If you need to use a date for source data selection, store and use the
highest date from the source system instead of using
lastSuccessfulRunDate.
• Split the Document, if necessary, before a Document Cache shape.

98
 5. Performance

99
Performance
• Minimize Connector Calls.
• Pull data together when possible (e.g., use joins on DB selects or SaaS
queries when available).
• Cache documents where appropriate.
• Function cache where appropriate.
• Avoid making repeated Connector or Database Calls on a per-document
basis where possible. Consider caching or other techniques.
• Minimize or eliminate use of “run each document individually” feature for
high-volume processes.

100
Performance
• Batching where possible.
• Parallel processing, if needed and appropriate.
• When writing to Netsuite, consider using externalids to avoid having to
look up internalids.
• Eliminate use of “map function ordering” if it is not needed.
• How many records per unit of time is this process expected to handle?
Has it been tested at this volume? If high volume, is this process set up
appropriately for high volume (caching, parallelism, etc.)?

101
 6. Final Checks

102
Final Checks
• Verify that the process is tested and documented.
• High volume processes should be performance tested.
• Be sure execution instructions are documented. What should a user do
if this process fails? Retry docs? Re-run process? Any resetting of flags
or dates?
• Identify who will monitor executions, and how.
• Verify that proper User Management is in place.
• On bi-directional synchs, be sure “ping-ponging” has been avoided. For
example, if accounts are synched from system A to system B in one
process, and then system B back to system A in another process, and if
both processes are run using “last mod date” logic, a record could
bounce indefinitely between one system and the other.

103
 Best Deployment
Practices Framework

105
Component Versioning
Each component has its own independent revision history. Every time you
save a change to a component, the Revision number is incremented along
with the user who changed it.
You can restore (roll back) to a previous revision of the component by
selecting a previous version and saving the component, but be careful
when restoring a component:
• Make sure other processes/components are not relying on the most
recent version.
• Restoring a previous version will not delete any other components
referenced by the newer configuration.
• The ‘Show Where Used’ feature should be used to see all the
components that reference a given component.

106
Environments
Deployments are made to logical containers called environments.
Environments are used to facilitate development lifecycle phases (e.g., dev,
test, prod) and enable change management by allowing different versions
of the same process to reside in different environments. Settings such as
connection credentials and global parameters can be configured per
environment using extensions.

An environment gives you greater control over change management and

supports different connection configurations with the use of extensions.
Integrations can be built, tested, and promoted between environments with
a full audit trail of what was deployed and by whom. Environments help to
ease the management of larger implementation projects that require the
use of multiple application setups, on-premises resources, and a
distributed architecture.
107
Environments
Typical Classification of Environments:

Dev: Where the developers perform their development activity,

including unit testing of development.
Test: Where the various components of the development are tested in
combination.
Prod: The final environment where the deployed processes run either
on a local atom or in the cloud.

108
Environments
Sample Ecosystem:

Sandbox: Local atom on the developer’s machine where initial test

mode testing can be done.
Test: Where the various components of the development are tested in
combination.
Dev: Where the developers perform their development activity,
including unit testing of development.
QA: Copy of production environment. Within this environment, new
releases should be applied so that proper regression testing can be
done.
Pre-Prod: Staging area for deployments to production environment.
Prod: The final environment where the deployed processes run either
on a local atom or in the cloud.
109
Use of Extensions
1.) Set fake values in the underlying components to protect against
inadvertently connecting to the wrong endpoint if an extension is
accidentally not declared on a given process or overridden in Atom
Management.

2.) Intentionally configure a placeholder value, such as “SET BY

EXTENSION,” for the actual connection or other to-be-extended
components. This enforces the best practice of always extending the
connection components and relying on environment extensions for values.
With this approach, if an extension is accidently not declared in a given
process, it will result in a connectivity exception instead of inadvertently
connecting to the wrong endpoint (for example, accidentally writing to
production during testing).

110
Use of Extensions
3.) Extend all connections across all processes. However, only extend the
connection fields that will actually change between environments.

4.) To configure some types of connector operations, you’ll need to

reference a connection with actual credentials. Keep a separate copy of the
connection components strictly for browsing use (and name them
accordingly). Make it a practice never to deploy them.

5.) When executing in Test Mode, you will need to provide values for the
extensions. Extensions are configured per Atom in the Run a Test dialog.
You will need to enter values for a given a process the first time you run a
test, but AtomSphere saves the extension values across test mode
executions.

111
Deployment Procedures
1. Perform development in the Build tab.
2. Perform unit testing with limited test data via Test Mode. Set connection and other
extension values via Test Mode Extensions. These values are saved per process per Atom.
3. Attach (first time only) and deploy the process to the first environment (Development) using
the Deploy Latest Revision of Process button. This creates a new deployment version.
4. Configure extensions for the process in the Development environment via Atom
Management.
5. Perform end-to-end testing in the Development environment.
6. Promote to the next environment (QA).
7. Configure extensions for the new environment.
8. Perform end-to-end testing.
9. Repeat steps 6 to 8 for each environment through Production.

112
117
Copyrights and Trademarks
This guide contains proprietary information protected by copyright and/or other legal grounds. The software described in this guide is furnished under a software license or nondisclosure
agreement. This software may be used or copied only in accordance with the terms of the applicable agreement. No part of this guide may be reproduced or transmitted in any form or by
any means, electronic or mechanical, including photocopying and recording for any purpose other than the purchaser’s personal use without the written permission of Boomi, Inc. (“Dell
Boomi”).

The information in this document is provided in connection with Dell Boomi products. No license, express or implied, by estoppel or otherwise, to any intellectual property right is granted by
this document or in connection with the sale of Dell Boomi products. EXCEPT AS SET FORTH IN THE TERMS AND CONDITIONS AS SPECIFIED IN THE LICENSE AGREEMENT FOR
THIS PRODUCT, DELL BOOMI (TOGETHER WITH DELL INC. AND ITS DIRECT AND INDIRECT SUBSIDIARIES) ASSUMES NO LIABILITY WHATSOEVER AND DISCLAIMS ANY
EXPRESS, IMPLIED OR STATUTORY WARRANTY RELATING TO ITS PRODUCTS INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTY OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. IN NO EVENT SHALL DELL BE LIABLE FOR ANY DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE, SPECIAL
OR INCIDENTAL DAMAGES (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS, BUSINESS INTERRUPTION OR LOSS OF INFORMATION) ARISING OUT OF
THE USE OR INABILITY TO USE THIS DOCUMENT, EVEN IF ANY OF THEM HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Dell Boomi makes no representations
or warranties with respect to the accuracy or completeness of the contents of this document and reserves the right to make changes to specifications and product descriptions at any time
without notice. Dell Boomi does not make any commitment to update the information contained in this document.

If you have any questions regarding your potential use of this material, contact:

Boomi, Inc.
Attn: LEGAL Dept.
legalnotices@dell.com

With a copy to:

Boomi, Inc., Legal Department, 1400 Liberty Ridge Drive, Chesterbrook, PA 19087

Trademarks
Copyright © 2017 Boomi, Inc. All rights reserved. Dell, the Dell logo, Dell Boomi, Boomi, AtomSphere, Atom, and AtomSphere Integration Cloud are trademarks of Dell Inc. and/or its
subsidiaries in the United States and/or other countries. Other trademarks and trade names may be used in this document to refer to either the entities claiming the marks and names or their
products.

118