Working Effectively with Oracle's Public APIs: Finding,

Understanding, Using, Tuning, and Extending

A White Paper (DRAFT)

Rob Lepanto, API Wizard

July 27, 2013

Working Effectively with Oracle's Public APIs 1

Contents
Abstract: .................................................................................................................................................... 3
About the author: ..................................................................................................................................... 3
Chapter 1: What is an API and how are they used? ................................................................................. 4
API Definition ........................................................................................................................................ 4
The difference between a 'Public' API and a 'Private' API .................................................................... 4
How are Oracle Public APIs used? ........................................................................................................ 4
Why is it important to use Public APIs? ................................................................................................ 5
Chapter 2: How to identify available APIs................................................................................................. 6
Chapter 3: Working with APIs ................................................................................................................. 11
De-facto Oracle Standards: ................................................................................................................. 11
Less common but often seen in module-specific APIs........................................................................ 12
Chapter 4: What to do when the API call fails? ...................................................................................... 13
Different failure types ......................................................................................................................... 13
Error Messages.................................................................................................................................... 13
Is it hard to debug APIs? ..................................................................................................................... 14
Chapter 5: Performance.......................................................................................................................... 15
Chapter 6: Going beyond what Oracle gives you: Wrappers and Private APIs....................................... 18
Wrappers............................................................................................................................................. 18
Private APIs ......................................................................................................................................... 19
Chapter 6: Conclusion ............................................................................................................................. 20

Working Effectively with Oracle's Public APIs 2

Abstract:
Recent releases of the E-Business Suite have more than 2500 public APIs available which can be
used to greatly streamline operations and integrate with other applications, yet there is much
ambiguity about whats available and how to best leverage them. This presentation will help
you understand whats available, the best sources for documentation and examples, standards
common across public APIs, peculiarities in specific modules, and advanced topics like API
performance tuning and extensions.

About the author:

Rob Lepanto has worked with the Oracle EBS for over 17 years as a technical consultant, DBA,
functional consultant, and project manager. Mr. Lepanto started his career working for
Andersen Consulting and IBM Global Services and then went on to found and grow a number of
niche EBS consulting firms. Mr. Lepanto currently works for API Wizard, a software company
which provides an integrated development environment to work with any Oracle API without
programming. In his latest role, Mr. Lepanto has been exposed to a very large number of
Oracle EBS customers and the APIs they want to use to streamline business processes.

Working Effectively with Oracle's Public APIs 3

Chapter 1: What is an API and how are they used?
API Definition

There are many different definitions of an Application Programming Interface (API) and the appropriate
definition varies depending on the context. Within the framework of the Oracle EBS, an API is a
software program which serves as an intermediary or interface between two other software programs
or between a software program and data.

The difference between a 'Public' API and a 'Private' API

As relates to the Oracle EBS, Public APIs are those APIs which Oracle has created for its customers to
use. Private, or internal, APIs are used for Oracle's internal processing.

Oracle EBS customers can use public APIs with the same confidence and expectation of support that
they can when using any of the EBS forms - they are just another mechanism for transacting with Oracle
EBS. There is some ambiguous distinction between a public, published and public, unpublished API but
in practical terms, all public APIs are supported by Oracle. This is important because many companies
use these public APIs for mission critical applications and interfaces.

How are Oracle Public APIs used?

Oracle Public APIs are used in a number of ways:

1) Interfaces between two systems: for example, if customers are created in another application,
such as salesforce.com, but need to get into Oracle EBS for invoicing, public APIs to load
customers (parties) can be used in real-time or batch to keep the systems synchronized.
2) Custom applications that an organization builds for instance, a more efficient way to enter and
manage service contracts could be built using a forms development tool and public APIs.
3) To load or update bulk data developers can write programs to load or update data using public
APIs
4) In API Wizard, a tool which allows you to leverage Oracle's public APIs using an Excel user
interface with no programming.

Working Effectively with Oracle's Public APIs 4

Why is it important to use Public APIs?

Along with open interfaces, public APIs represent the only safe, supported way to enter data in Oracle
EBS aside from Oracle forms.

"(Public) APIs are guaranteed to maintain the integrity of the database Invalid data cannot be entered
into the system and existing data is protected from incorrect alterations."

Oracle Implementation Guide

If data passed to a public API does not pass validation, an error is returned which indicates that the API
did not make any changes to Oracle data and an error message is returned identifying the cause of the
error. Typically, the public API error messages are identical to error messages seen in the Oracle forms,
as both the public APIs and the forms utilize the same, underlying internal APIs and programs.

Working Effectively with Oracle's Public APIs 5

Chapter 2: How to identify available APIs

There are over 1,500 public APIs in R11 and over 2,500 public APIs in R12. With so many available,
there's a very high likelihood that there is an API for whatever you need to do. There are some
processes where there are both public APIs and Open Interfaces, some processes where there is one or
the other, and some processes where there are neither. New versions / patchsets of Oracle can contain
new APIs Oracle is working to have every process be available through either an API or open interface.

Finding the correct public API for a particular business process or task can be daunting, partially because
there are so many to choose from, partially because Oracle hasn't been methodical in how it releases
information about public APIs, and partially because many developers just don't know where to look.

When looking for a public API, here are some useful resources:

Oracle Integration Repository

The Oracle Integration Repository is a set of html forms in EBS R12 that are accessed via the 'Integrated
SOA Gateway' responsibility. The integration repository is probably the single best source of API
information that Oracle provides. It contains roughly 75% of the public APIs and open interfaces and it
has a fairly useful search mechanism, either by drilling down from module to business process via the
menu on the left-hand side of the form or by searching on keywords in its search box. When you find a
hit on the API that you are looking for, it also provides some rudimentary information about the API,
including its parameter definition.

Working Effectively with Oracle's Public APIs 6

The following is a screenshot of the Integration Repository in Oracle 12.1.1

One nice aspect of the integration repository is that it is intended to be updated whenever new APIs or
integration points are added, so if a recently applied patchset includes 20 new public APIs, they should
be documented here.

The integration repository is only available in R12. If you are still running R11, you must use one of the
other options to find API information.

irep.oracle.com

irep.oracle.com is Oracle's hosted integration repository. As of the writing of this document,

irep.oracle.com has been down for a number of months and Oracle has not said anything more than
what is contained in the following screenshot:

Working Effectively with Oracle's Public APIs 7

If and when iRep is available again, it can be a useful resource. Organizations running R11 can use this
to search for an API and then query their R11 system to see if that API existed as part of R11 (more than
50% will). Organizations on R12 can use it to determine if there are useful APIs in a later patchset than
the one they're currently on.

Of course, to be useful at all it needs to be online. If we all let Oracle know this is a useful resource,
perhaps they will put a little more effort into getting it back up

Oracle Documentation

You can find documentation on most versions of the Oracle EBS at:

http:// docs.oracle.com

API information can sometimes be found in the module-specific documentation. This information might
be provided in a technical/integration manual for the module or in the module user or reference guide.
Due to a lack of consistency, it takes some sleuthing to find API information in the Oracle documentation
but it can be worth it if it exists (which is not always the case) because the documentation has the most
precise explanation of the API rules and behavior, often with some sample code to help the reader
understand how to make a call using that API.

Web Search

Whether you use Google, Bing, etc., a web search is a very useful way to find API information. There is a
plethora of forums where questions about Oracle public APIs are asked and answered as well as many
useful blogs by developers who have successfully mastered one or more public APIs. The blogs are
particularly useful because they often contain sample code which you can use as a test case in your
environment with some tweaking.

My Oracle Support Search

Oracle's support site, support.oracle.com, can be somewhat useful when searching for API information.
While a general web search is probably more effective, sometimes you can find information about more
obscure public APIs on the support site. When searching, it's helpful to search in all categories, even
including the bug database - the goal is typically to find the name of the API you need and even a bug
involving the API can give you the name!

Raise a Service Request (SR) with Oracle Support

Public APIs are part of your licensed Oracle EBS system and are fully supported when you have issues.
You can raise a service request with Oracle Support for assistance identifying the correct public API to
use for a given business process. Depending on the analyst, they may help or they may refer you to
Oracle Consulting. It's often worth a try.

Working Effectively with Oracle's Public APIs 8

Consulting / Professional Services Providers

If you find a services provider which specializes in the area of EBS that you are looking to address, they'll
often be a good source of knowledge regarding APIs.

API Wizard

API Wizard provides a free service at www.api-wizard.com/FindAPI.html where you can request info on
a particular business process and the API Wizard team will try to point you in the right direction.

Query DBA Objects

This last option involves guessing the API name based on the business process. Most public APIs have
the words 'pub' or 'api' in them, which helps narrow down the field. For example if you were looking for
an inventory item API, you could search on the word ITEM as follows:

Tells Oracle to only consider packages: all

SELECT distinct object_name pkg, procedure$ proc public APIs are pl/sql packages.
FROM dba_objects obj, sys.argument$ args
WHERE obj.object_id = args.obj#
AND obj.object_type = 'PACKAGE' Tells Oracle to only consider packages:
AND obj.owner = 'APPS' owned by the APPS schema (all public
AND ( obj.object_name LIKE '%API%'
OR obj.object_name LIKE '%PUB%' APIs are owned by APPS)
)
AND args.procedure$ LIKE '%ITEM%' Public APIs typically have the word 'API'
ORDER BY object_name, procedure$
or 'PUB' within the name.

A guess at the procedure (activity name).

You could also guess at the API name by
coding 'AND obj.object_name LIKE
'%ITEM%'

In 12.1.3 the above query returns over 500 matches. In a sense, this is great there is a lot of item APIs
that you can use but for the purposes of finding the right API, the field is still too large. A nice way to
parse this list down further is to think about one of the parameters that you would expect to enter or
update when working with this API. For item processing, you might search on ITEM_NUMBER (which
seems a little counter-intuitive since there really isn't an item_number field in the item tables, it's a key
flexfield but it turns out some public APIs to use this as a parameter name) or for INVENTORY_ITEM_ID
which you would definitely expect an item API to have as a parameter. However, if you just add the
parameter name 'INVENTORY_ITEM_ID' it actually doesn't restrict the resultset they all use that
parameter! OK, so it helps to pick something that is more specific for what you want to do. If you want
to update inventory items, look at mtl_system_items and try a field name from that table, like
'LEAD_TIME_LOT_SIZE'. Add that to your query as follows:

Working Effectively with Oracle's Public APIs 9

SELECT distinct object_name pkg, procedure$ proc
FROM dba_objects obj, sys.argument$ args
WHERE obj.object_id = args.obj#
AND obj.object_type = 'PACKAGE'
AND obj.owner = 'APPS'
AND ( obj.object_name LIKE '%API%' There's a very good chance that an API
OR obj.object_name LIKE '%PUB%' with the parameter 'LEAD_TIME_LOT_SIZE'
)
AND args.procedure$ LIKE '%ITEM%' will be the one we are looking for. You can
AND args.argument LIKE '%LEAD_TIME_LOT_SIZE%' use this approach with any API search.
ORDER BY object_name, procedure$

Presto! Now we are down to three possibilities:

We can review these APIs if needed to identify the correct one. It turns out that the one we want is
ego_item_pub.process_items!

In summary, querying dba_objects and sys.argument$ can be an effective way to find API information by
querying against the database.

Working Effectively with Oracle's Public APIs 10

Chapter 3: Working with APIs

Once the required API has been identified, the next question is how to work with it. Unless you use the
API Wizard software, the typical way to work with an Oracle API is to create a pl/sql program, minimally
an anonymous pl/sql block, to call the API. First, let's start with some of the de-facto standards for
Oracle's public APIs.

De-facto Oracle Standards:

1. All of the pl/sql public APIs are procedures or functions within packages. The naming
convention is that the API name equals the package name, however a given API (package) can
have many (dozens potentially) of procedures or functions.

2. The vast majority of public APIs use these standard, default output parameters:
a. p_api_version Oracle has not yet made use of this parameter, despite it typically being
required. Passing a default value of '1' is generally a good bet.
b. p_init_msg_list This controls whether or not the message list should be initialized
when the API is executed. The message list is important in output message processing
which is discussed later in this document. In almost all cases, this should be set to'T' for
True.
c. p_commit This controls whether the API should commit after each execution. You can
use set this value to 'T' (true) to have the API commit or the commits (or rollbacks) can
be handled in the calling program.

3. The vast majority of public APIs use one of the sets of standard, default output parameters:
a. p_return_status, p_msg_count, and p_msg_data
b. x_return_status, x_msg_count, and x_msg_data

These standard output parameters have some special processing logic associated with them
which is described later in this document.

4. Initializations

Some APIs require environment initialization and others do not. There are APIs that require
setting the user, responsibility, application, mo_global, and organization, others that require a
subset of those, and others do not require any. Proper environment initialization can often be
the difference between successful and unsuccessful API processing. It's best to assume the
standard initializations are required.

Working Effectively with Oracle's Public APIs 11

 A frequently asked question with respect to APIs and environment initialization is whether or
not APIs support multi-org security. The answer is that some do and some don't. Some APIs will
let you manipulate data in any org even if you've properly initialized a specific org. If this is the
case, you must handle the multi-org security in the calling program.

5. Flexfields

Nearly every public API allows you to import or update flexfield data.

Less common but often seen in module-specific APIs

1. p_record_version_number
2. No status parameter
3. No messages parameters
4. Special messages parameters

Working Effectively with Oracle's Public APIs 12

Chapter 4: What to do when the API call fails?

Different failure types

There are two main types of failures that you see when working with public APIs.

The first is a standard programming error that you run into when you don't include the required
parameters or you try to pass an invalid parameter value datatype to a parameter (for instance, passing
characters to a parameter with a numeric datatype). In this case, you receive an ORA-06550 wrong
number or types of arguments. These types of errors can be avoided by reviewing the API
documentation and double-checking the parameters in your API call and the data you're passing. If you
can't find documentation for your API, you can view it in user_source and see which parameters do not
have default values (i.e. which makes them required) and what the datatypes are.

The other type of failure is a logical failure. You can make a valid API call (pass the minimum required
number of parameters and all values are using correct datatypes) but your data fails the API validation.
There can be countless possible reasons. In many cases, the error messages produced by the API are
useful in diagnosing the issue, although this isn't always the case. To diagnose this type of error, first
start with the API error message. If that doesn't help, try removing all of the parameters that are not
required and see if that works. If so, then add additional parameters back one at a time until you find
the issue. You can also review the error or the APIs functionality in the documentation or by doing a
web search. If none of the above work, you should raise an SR with Oracle.

Error Messages

In general, the public APIs have one or more output parameters to which error messages are written.
The most typical parameters for this purpose are p_msg_data or x_msg_data. Some APIs have other
error output parameters, some write messages to error tables, others just put error messages in the
FND message buffer.

For those APIs that use p_msg_data or x_msg_data, you generally need to check the number of
messages being returned in another parameter, typically p_msg_cnt or x_msg_cnt, to determine if there
is one message or more than one message. When public APIs return a single message, they typically
pass that value to the p_msg_data or x_msg_data parameters. However, when public APIs return
multiple messages, they typically bypass the p or x_msg_data parameters and post their messages to
the fnd message buffer.

In the case where there are multiple messages for an API using p or x_msg_data or for those APIs
without those parameters and not using an error table, then you need to grab the messages from the

Working Effectively with Oracle's Public APIs 13

fnd message buffer using the public API fnd_msg_pub.get. Typically you would use the message count
from the API and run the fnd_msg_pub.get routine in a loop to grab all of the messages for a given API.

Example of getting API messages using fnd_msg_pub with output parameters p_msg_count and
p_msg_data:

IF nvl(p_msg_count,1) = 1
THEN
dbms_output.put_line(p_msg_data);
ELSE
FOR i in 1 .. p_msg_count
LOOP
dbms_output.put_line
(fnd_msg_pub.get
(fnd_msg_pub.g_next, fnd_api.g_false) || i);
END LOOP;
END IF;
END;

Sometimes the output will include characters that you will want to remove before presenting. For
instance, if you want to remove ASCII character CHR(0), you could do the following (assuming output is
in variable v_output_message).

v_output_message := replace(v_output_message, chr(0), ' ');

Is it hard to debug APIs?

The following is from a post in an online Oracle forum

It's always more difficult to debug someone else's code than your own and it takes a methodical and
patient approach. Having said that, debugging an API isn't that hard. There is often a fair amount of
information available online and you can enter an SR with Oracle if the API is not working properly.

As discussed above, the APIs generate messages that can be very useful in debugging. Additionally, all
of the public API code is unencrypted, so it is easily viewable in user_source. This allows you to use all of
the same debugging techniques that you would with any other code, including things like tracing
which can greatly simplify the debugging process. Additionally, you can make a copy of the API and add
your own debug messages as a way to streamline the debugging process.

Software debugging is an art in and of itself; for this document, the salient point is that it is no harder to
debug a public API than any other software program that someone else has written.

Working Effectively with Oracle's Public APIs 14

Chapter 5: Performance

While the API code itself can't be changed, there are steps that can be taken to improve performance:

1. Trace and Indexes

Sometimes the right index can have a huge impact on performance. By running a trace on the
API, bottlenecks can be identified. To the extent that these bottlenecks are due to SQL queries
(which are used extensively during API validation), it's a fairly simple matter to identify and
create indexes to improve their performance. This is a process that can be performed iteratively
until all sql-based bottlenecks are resolved.

2. Parallel Execution

When a large number of records need to be processed, performance is often improved by

running the API in multiple, parallel executions. This will often result in greatly reducing the
overall runtime. Depending on the process and the data being updated, parallel execution can
potentially cause contention, so it's critical to test and assess the overall impact of this
approach.

3. Coordinating activity

Other system activity can affect performance of APIs and APIs can affect other system activity.
When processing a large number of records, it's a good idea to understand what else is running
in the system at the same time. Consider running the API at a time of low system utilization to
maximize performance.

4. Data preparation:

The Oracle database caches recent queries. This means that it leaves in memory information
that is recently requested (as well as information that is repeatedly requested). If it is possible
to order API executions so that data which is logically related is executed in a cluster, there is an
increased likelihood that validation queries will be resolved from cache rather than needing to
retrieve the information from the physical hard-drives, which can be a big time saver.

An example would be using an API to load customer invoices. Validations on invoices would
likely include verifying the party, the customer, the bill-to and ship-to locations, the payment
terms, whether the customer has a credit-hold, etc. If there are multiple invoices to load for the
same customer and these are processed one right after the other, there is a very good chance
that after the first execution, a great deal of the validation information will be in memory, which
will greatly improve performance.

Working Effectively with Oracle's Public APIs 15

 5. Commit frequency

It's a general database issue but commit frequency can have an impact on API performance.
Committing represents making pending changes permanent. Pending changes are stored in a
special area of the database. While changes are pending, the database must do extra work to
keep track of those changes so that the person requesting the change can decide to commit
(save) or rollback (cancel) and to also provide other users with an unaltered view of the data.
When commits are too infrequent, this overhead can cause performance degradation as well as
potential contention, which can include unpleasant things like table and row locks. Frequent
commits can also have a performance impact, as commits have some overhead associated with.

It's beyond the scope of this paper to dive into this issue in more detail but it is worth noting
that finding the correct commit frequency can help improve performance.

6. Using Internal IDs

Some public APIs provide the option to pass either internal identifiers (e.g. party_id) or the more
common identifiers recognized by users (e.g. party_name or party_number). When the internal
identifiers are not passed, then the API will need to do a lookup at some point to derive those
values. Passing the internal identifiers directly to the API saves that step and can improve
performance.

7. Pre-validate

When duration is a concern, it can be helpful to pre-validate data before the actual API
execution. Pre-validation can help identify errors or other issues that will impact the actual API
run. By identifying and addressing potential issues ahead of time, when timing is not as critical,
the actual production run will be more streamlined. While some APIs have a validate option,
any API can be used in a 'validate' only mode by performing a rollback. This approach can be
used regardless of the size of the dataset to be processed.

8. Pinning

A public API is a pl/sql procedure within a pl/sql package. There may be one or more
procedures within any given package.

When an API is first called, that API along with all other procedures in its package, are loaded
into the databases shared pool (a memory area). For large and complex APIs, this can cause a
noticeable delay to the beginning of processing. This delay has a greater impact for APIs that
are run moderately frequently but with small data volumes, where each time the API is
executed it's already been aged out of the shared pool. For APIs where a lot of data is being run

Working Effectively with Oracle's Public APIs 16

 at once, this is less of an issue as the first execution may be slow but subsequent executions will
be able to access the API within the shared pool.

To improve performance, APIs can be 'pinned' or kept permanently in the shared pool so that
they are always readily accessible. While doing this helps the API that has been pinned, the
reserved memory is not available for other processes. If the shared pool is too small, this can
lead to a performance hit somewhere else.

9. Patches

Oracle provides patches for poor performing APIs. If there is already a patch available for a
poorly performing API, then this is a great option. If there isn't already a patch, requesting one
from Oracle is a logical approach. They might also have performance improvement tips for
particular APIs.

Working Effectively with Oracle's Public APIs 17

Chapter 6: Going beyond what Oracle gives you: Wrappers and Private
APIs

The Oracle public APIs are powerful and can help process all types of transactions against Oracle. There
are times when requirements call for something above and beyond what the public APIs deliver. Those
requirements might include applying additional logic before or after a public API call or to interact with
data for which no public API exists.

Wrappers

Within the context of Oracle public APIs, a wrapper is a program which provides a shell for calling
multiple APIs, performing validations, and/or performing output translations. This allows organizations
to utilize the Oracle public APIs in a way that meets their precise processing requirements. Wrappers
are typically simple programs that perform a few specific tasks but can also be incredibly involved and
complex if requirements dictate.

Calling Multiple APIs

There are several business processes where multiple APIs are required to accomplish a business task.
For example, in R12, creating a customer requires the use of several APIs. A wrapper can simplify
working with such a process by coordinating the relationships between APIs. A single, consolidated
wrapper will be easier to use than having to work with multiple APIs each time there is a requirement to
create or update customers programmatically.

Validations

Public APIs perform all of the validations required to determine whether the data passed creates a valid
Oracle EBS transaction. If it does not, the API returns with an error status. Some organizations have
rules that go beyond the standard Oracle EBS rules, which may be setup as form personalizations,
codified as on-insert or on-update database triggers, or controlled via a business process. Wrappers can
be used to enforce any additional logic or constraints when working with public APIs. For example,
staying with the customer example, if an organization has a rule that specifies the maximum credit limit
for a new customer as $10,000, that rule can be created as a validation in the wrapper which is tested
before calling the API. If data is passed to the wrapper with a credit limit greater than $10,000, then the
wrapper would raise an error and not call the API. Any type of validation can be performed in this
manner.

Message Translations

Many Oracle public APIs use fairly sensible and easy to understand output messages. However, in some
cases messages can be confusing. Wrappers can be used to simplify messages so that they are more

Working Effectively with Oracle's Public APIs 18

meaningful to the person receiving them. In order to use a wrapper in this manner, all of the potential
output messages should be identified and mapped to more readily understood messages.

Private APIs

Up until this point of the white-paper, every suggestion and example has focused on working with
Oracle's public APIs in a manner that is consistent with Oracle's software license and support terms.

There are some business processes for which Oracle has provided neither a public API nor an open
interface and, at times, there is a requirement to programmatically work with these processes never-
the-less. In general, there are two ways to do this: working with private APIs and base-table updates
neither approach is supported by Oracle.

A base-table update refers to directly manipulating data in the Oracle EBS base tables. This is generally
considered a high-risk proposition as underlying Oracle data is stored in a somewhat confusing manner
which is not totally normalized. If done incorrectly, there is a risk of data corruption. Never-the-less,
many companies do perform direct table updates from time to time. Risk is reduced by careful and
thorough analysis and testing,.

Better than performing base-table updates is to work with private APIs. These are similar to the public
APIs but their direct use is not approved by Oracle. However, they are used extensively within the
Oracle EBS: in fact, nearly every transaction in the Oracle EBS called both by user forms and by public
APIs result in private API calls.

While not supported, private APIs typically offer a fairly easy way to create or update Oracle
transactions with less risk than direct table updates. The key is to find the correct private API and the
easiest way to do this is to start with the user forms for the target business process and either open up
their code or perform traces while entering test data. Once the correct private APIs have been
identified, they are about as easy to work with as public APIs with the exception of Oracle not providing
any documentation or help. Private APIs are unencrypted pl/sql procedures which can be readily
reviewed, traced, and tested using the methods outlined in this document.

Working Effectively with Oracle's Public APIs 19

Chapter 6: Conclusion

Oracle has invested heavily, over the last several years, in exposing APIs for customer use. This is
evidenced by the significant increase in public APIs between R11 (1,500) to R12 (2,500). Additionally,
the introduction of the Integration Repository was a big step forward in making API information
accessible for customer use.

Public APIs offer a safe and effective way to perform Oracle EBS transactions and provide an excellent
mechanism for creating interfaces between systems, providing flexibility in data conversions, or
streamlining business processing within the API Wizard efficiency platform for Oracle.

While it isn't always easy to find particular APIs, they do exist for nearly every business process. With
some ingenuity and effort, they can be identified, understood, tested, tuned, extended, and utilized.

Public APIs represent the 'right' (i.e. safe and supported) way to work with your Oracle EBS data.

Working Effectively with Oracle's Public APIs 20