Client Case Study- Integrating ServiceMax and Oracle EBS

A leading manufacturer of commercial printing solutions integrates Oracle EBS and ServiceMax to increase cost savings and time optimization.

Solution Background

The customer provides graphic and precision solutions and is headquartered in Japan with its North America office located in Chicago, IL. They are one of the largest manufacturers and suppliers of system components for the prepress and printing industries worldwide. 

After implementing ServiceMax to manage their after-sales operations, the customer needed to integrate ServiceMax with its back-office Oracle E-Business Suite (R12) system. The customer needed ennVee’s help to create a holistic solution, enabling the seamless and automated exchange of data between Oracle E-Business Suite and ServiceMax.


Key Requirements:

Build interfaces between Oracle E-Business Suite and ServiceMax to automatically:

  • Send and receive all order information to process the order in Oracle Order Management.
  • Synchronize the work order information in both systems.
  • Handle all errors, exceptions, or reconciliation requirements.


ennVee Solution

ennVee developed interfaces to connect Oracle E-Business Suite and ServiceMax, and designed a custom solution to automate the following processes:

  • Raising and Tracking Service Requests in ServiceMax, and integrating the requests with Oracle E-Business Suite.
  • Maintaining parts prices in sync across both systems.
  • Sending Work Order information to ServiceMax.
  • Creating labor orders in Oracle Order Management before processing them for invoicing.
  • Validating the order, returning used parts to inventory, and taking the line to closure in Oracle E-Business Suite.


Eight key business process functionalities were addressed:

  1. A work order is entered into ServiceMax and a sales order is entered in Oracle E-Business Suite whenever there is request from a customer for parts installation.
  2. A sales order entered into Oracle E-Business Suite will contain the quantity of the order placed and picked by the Engineer.
  3. An interface sends the information to ServiceMax, and the work order number in ServiceMax is updated along with the parts that are selected for installation.
  4. After the installation is done at customer site, labor and expense charges are entered in ServiceMax for the respective work order.
  5. Information is brought into Oracle E-Business Suite to create a sales order for the invoices and labor charges.
  6. The Engineer inputs the parts used during installation into the work order and completes the work order.
  7. This information is also brought into Oracle E-Business to perform a back order for any unused parts and to close the order line.
  8. There is an interface that runs daily to synchronize the prices of the parts in Oracle E-Business and ServiceMax, and sends over any parts that have undergone a price change or were recently added (new parts).


Solution Approach

We designed and built four interfaces that would provide the various functionalities required by the customer. 

  • Interface 1 – Outbound from Oracle EBS (to extract the parts and pricing information to be sent to ServiceMax). Data will be extracted from Oracle EBS into a .CSV file, which will be sent to an inbound ServiceMax server via FTP.
  • Interface 2 – Outbound from Oracle EBS. Whenever a service request is raised for installation of parts, a sales order is created in Oracle EBS. This order will have customer information, work order number, parts (items number), quantity, price, engineer bin location, shipped quantity, picked quantity, etc. All of this information is extracted and sent to ServiceMax via .CSV file.
  • Interface 3 – Inbound to Oracle EBS. An Order for Labor charge will be entered in ServiceMax and sent to Oracle EBS for a sales order creation. After, a sales order for the labor/service charges will be created in Oracle EBS and invoice-ready.
  • Interface 4. The engineer will enter the parts used and all detailed information when the work order number is closed in ServiceMax. This information will be pushed to Oracle EBS, similar to the work order number, parts consumed, closing comments, work order closed date, etc.


Business Benefits

As a result of the new integration between ServiceMax and Oracle E-Business Suite, the customer benefitted immensely from a cost savings and time optimization standpoint. With an automated process for raising, tracking, and accessing Service Requests in Oracle E-Business Suite, the customer was able to reduce operational costs, nearly eliminating any manual intervention in the Service Request process. Automating the flow of data between systems enabled drastic business growth and yielded a faster exchange of data across the system.


Visit our website for additional case studies.


Customer Voice: “Patching, Testing, Migration, and Downtime…” are among the most reported Oracle EBS R12.2 upgrade challenges

ennVee partnered with an independent research firm to survey 300+ IT and project leaders who have or anticipate upgrading to Oracle E-Business Suite R12.2. Respondents cover all major industries. The top reported challenges include Downtime, Migrating Customizations, and Patching and Testing. 


Oracle E-Business Suite 12.2 was first released in September 2013. It introduced Online Patching to help customers ensure continuous operation of their key business process. The underlying technology stack was also overhauled and supplemented with Oracle Fusion Middleware. As a result, all standard and custom objects (customizations) need to undergo numerous code changes to ensure compliance with 12.2 and above. While Oracle provides a standard utility for remediating and migration standard objects, the utility does not apply to any non standard (custom) objects. As a result, customers must make manually remediate and migrate all custom objects to their target R12.2 instance.


Our objective was to determine if the extent of customization was universally perceived as one of the top challenges for customers who have upgraded or are planning to upgrade to Oracle E-Business Suite R12.2. ennVee partnered with an independent research firm to survey 300+ IT and project leaders who have or anticipate upgrading to Oracle E-Business Suite R12.2. Respondents cover all major industries. The top reported challenges include Downtime, Migrating Customizations, and Patching and Testing.

Download our infographic for a breakdown of R12.2 upgrade objectives, challenges, estimated timelines, and the impact of customization.

About ennABLE

ennVee has been helping customers eliminate a bulk of the heavy lifting by automating the R12.2 upgrade process (from Assessment to Remediation, Migration, and Testing). Our proprietary ennABLE accelerator dramatically reduces the hours associated with custom object remediation, and reduces project cost and timelines by 50%, while minimizing cutover and upgrade downtime.

2017 Gateway OAUG Kansas City – Event Recap

ennVee President, Veera Venugopal, and Vice President of Global Sales and Marketing, Joe Bong discussed current and future Oracle E-Business Suite and ERP upgrade automation trends, and other key aspects that make or break the R12.2 upgrade process.

The second annual Gateway OAUG event took place this past Wednesday, November 8th in Overland Park, Kansas. ennVee participated as an exhibitor and hosted a session around Oracle E-Business Suite R12.2 upgrade automation. Download presentation.


ennVee President, Veera Venugopal, and Vice President of Global Sales and Marketing, Joe Bong discussed current and future Oracle E-Business Suite and ERP upgrade automation trends, and other key aspects that make or break the R12.2 upgrade process.

Veera Venugopal provided insight around the current state and automation best practices during Oracle EBS R12.2 upgrades, as well as the benefits of upgrading to the latest release 12.2.7.

Joe Bong addressed the “voice of the customer” by summarizing the results of over 2,000 surveys taken by Oracle ERP/IT decision makers across all major industries. Joe also examined ennVee’s proprietary automation tools and processes that when applied reduce cost, manual effort, and time to go-live by 60%. The session concluded with a look into ennVee’s Oracle Discoverer migration solution and Oracle Application Performance Monitoring/Managed Services, where 60% of manual effort is eliminated via automation.

Discuss your Enterprise Resource Planning (ERP) objectives with us

Are you preparing or planning to upgrade to Oracle E-Business Suite R12.2.7? Contact us to accelerate and reduce the cost of your upgrade by 60%.

ennVee to Host Session on Oracle E-Business Suite R12.2 Upgrade Automation at Upcoming OAUG Event

ennVee will be presenting and exhibiting at the upcoming Gateway Kansas City OAUG event on November 8th.

We’re excited to announce that ennVee will be presenting and exhibiting at the upcoming Gateway Kansas City OAUG event on November 8th.

Make sure to catch our Customer Experience session hosted by ennVee President, Veera Venugopal and Vice President of Global Sales and Marketing, Joe Bong. Both will discuss ways in which customers can leverage automation to accelerate the Oracle E-Business Suite ERP upgrade process to the latest R12.2 release. 

About our Session

Automation: Or How We Eliminated Manual R12.2 Upgrades and Become Cost Saving Hero
Who doesn’t want peace-of-mind from their Oracle E-Business Suite R12.2.7 upgrade? President and Vice President, Veera Venugopal and Joe Bong will discuss how project and business teams can expedite R12.2.x upgrade process through automation. We will share tips, best practices, and lessons learned from past upgrades, which will help you leverage automation to create efficiency, reduce time and cost, while increasing quality.

When: Wednesday, November 8th from 10-10:40AM CDT.
Where: GRID Collaborative Spaces, 12022 Blue Valley Parkway, Overland Park, Kansas 66213

Full agenda and registration –

Learn more about the centerpiece of our session, ENNABLE

MuleSoft API Lifecycle Management

Learn about the lifecycle of an API managed with MuleSoft, from the design and build stages, to implementation and management.

Learn about the lifecycle of an API managed with MuleSoft, from the design and build stages, to implementation and management.

thumbnail   By: Arun Yaligar

1. Introduction

In today’s competitive landscape, businesses need to make decisions quickly; whether it’s a new marketing campaign, a new product enhancement, a new partner portal, or an employee productivity app, businesses are competing on speed. What is needed is flexibility. And what better way to do this than to create purposeful, agile application building blocks that can be easily pieced together with well-designed, well-managed APIs to quickly create what is needed. Connecting these building blocks results in a network of interchangeable functionality — a network of sub-functions, or applications. We call it the application network.

Let’s future-proof ourselves and hedge against uncertainty by creating these building blocks, and then allow for the flexibility to rapidly piece them together on an on-demand basis.

1.1 Welcome to the Application Network

The application network is the future. It emerges from the creation of multiple API-enabled microservices; connecting these microservices with a strategic API approach results in a composable network. The network allows the flexibility to rapidly piece together different services for multiple functionalities an on-demand basis, providing business agility and a robust platform for innovation.


1.2 The Anatomy of an Application Building Block

An application network is composed of application building blocks. These have multiple elements. and it’s critical to separate the concerns between each. The API interface, the API implementation, and the API management aspects all have their own specific, unique lifecycles to follow. This building block should itself be treated as a product since these characteristics are common to what a good product should also have. Therefore, it makes sense to treat a building block from a product-centric approach.

We see this product-centric lifecycle as having three distinct stages: design, implementation, and management.


1.3 The Lifecycle of an Application Building Block

4 (1)

2. Design

2.1 How to Design an API

Designing an API starts with an acknowledgment ahead of time that the API production process will start from an outside-in perspective, beginning with the “interface/contract” of the API. That is to say, let us first decide what the API will look and behave like before we actually begin to code the backend logic.

Often, developers build APIs without knowing the API has been validated and accepted. As a result, there is always this air of uncertainty: “Is this what my consuming developers want?”

2.2 “Outside-In” Done Right

API developers must design the user interface of the API first – this is also known as the API contract. This approach is typically known as a “design-first” approach, and it should follow a deliberate API design lifecycle in order to optimize for the best API experience. As a result, it is important to be able to do this in a human-readable fashion — to specify the contract in a way that humans can easily digest.


2.3 Soliciting Feedback on the API’s Design

At this point in the process, the API designer (i.e. the designer of the API contract) is ready to have the API validated and tested by the API consumers (i.e. a client mobile app/website developer, or another API provider in some cases).

The currency of conversation between both parties will be interactive tools such as the API Notebook and interactive documentation, to name a few. There are many other tools that can be referenced from the site. This process of validation may be brief or extended over numerous iterations.

2.4 Repeatable Design

Any well-designed API will have repeatability, as well as repeatability across other APIs. This can easily be encapsulated into best practice patterns both at the structural level of the API (nouns/resources), as well as at the method level (verbs). So as API developers go about the design process, it is important to be able to discover and share repeatable patterns.

3. Implementation

3.1 Connect Systematically, Not in an Ad-Hoc Fashion

API implementation is a critical piece in enabling a next-generation enterprise. Enabling for dozens, potentially even hundreds or thousands of APIs to be connected down to a backend and connected to each other will be key. This must be done in a systematic manner (as opposed to point-to-point code).


3.2 Put API Design Principles and Best Practices in a Common Repository

Benefits of a best practices repository:
• Increase business agility.
• Share best practices with reusable templates and logic.
• Leverage best practice patterns.
• Rapidly deploy APIs: fail fast, succeed faster.
• Minimize point-to-point logic and future-proof for stability.

3.3 Testing the API Implementation

At this point in the process, the API provider (i.e. the developer behind the API implementation) is ready to have the “guts” of the API tested. MUnit is MuleSoft’s testing solution, which is incorporated into the full application building block lifecycle. Test automation tools are critical here, as this integrates into the DevOps processes of continuous
delivery and deployment.

4 Management

4.1 Embrace DevOps

Embracing modern DevOps-centric processes and tooling is critical to reducing mean time-to-production, and this should apply to your application building blocks as well.


Once the application building block has been assembled and tested, deployment should be as easy as the click of a button.

The use of a hybrid integration platform that is lightweight, easy to install, and suitable for CI/CD workflows is key. The ability to have seamless support for dependency management, testing, version control, and automated deployment tooling should be an assumption.

4.2 Govern and Secure All Traffic

It is critical to ensure your application building blocks are following best practices in security and
architectural governance by applying policies to them at runtime. Monitoring all traffic is equally critical because it just takes just one weak link to bring the ship down.


4.3 Don’t Forget About the Discoverability and On-Ramp

Imagine your company with hundreds — if not thousands — of APIs in your expansive application network. Imagine you’re adding several new ones every day.

Being able to appropriately publish them so the consuming developer can find, research, and understand them easily could make or break your entire program. There is no point in building something that won’t ever be found, let alone used.


4.4 Just Like Any Product, Application Building Blocks Change

Building blocks will change. It’s a WHEN, not an IF, so be ready for it, which requires a carefully planned set of policies, procedures and the right platform to seamlessly migrate clients across new versions of APIs.

Getting this migration wrong will affect your customers. That’s not a risk worth taking.

10 (1)

It takes a village to have an application network.

So, Now What?

For more background on full lifecycle API management, take a look at the Gartner Magic Quadrant, in which MuleSoft is a Leader. You can also take a look at their further resources on API strategy and API development.

Arun Yaligar is a MuleSoft Developer at ennVee. Learn more at

This article was originally posted to The Integration Zone