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

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: API Wizard and Oracle APIs................................................................................................... 20 Chapter 7: Conclusion ............................................................................................................................. 21

Working Effectively with Oracle's Public APIs

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 presentat ion 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.

About API Wizard:

Chapter 6 introduces API Wizard, the Oracle EBS Productivity Platform, which is used by Oracle customers around the globe to greatly streamline EBS data entry, data updating, and reporting. API Wizard provides a very efficient Microsoft Excel user interface for any process. Users work in Excel while the API Wizard backbone and engine works in Oracle and leverages Oracle's key constructs such as the public APIs, open interfaces, security, etc. The API Wizard development environment allows for rapid development by working with any API without programming, allowing solutions to be deployed in record time.

Working Effectively with Oracle's Public APIs

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

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

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

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

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

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 public APIs are pl/sql packages. Tells Oracle to only consider packages: owned by the APPS schema (all public APIs are owned by APPS) Public APIs typically have the word 'API' 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:

SELECT FROM WHERE AND AND AND

distinct object_name pkg, procedure$ proc dba_objects obj, sys.argument$ args obj.object_id = args.obj# obj.object_type = 'PACKAGE' obj.owner = 'APPS' ( obj.object_name LIKE '%API%' OR obj.object_name LIKE '%PUB%' ) AND args.procedure$ LIKE '%ITEM%' ORDER BY object_name, procedure$

Working Effectively with Oracle's Public APIs

SELECT FROM WHERE AND AND AND

distinct object_name pkg, procedure$ proc dba_objects obj, sys.argument$ args obj.object_id = args.obj# obj.object_type = 'PACKAGE' obj.owner = 'APPS' ( obj.object_name LIKE '%API%' OR obj.object_name LIKE '%PUB%' ) AND args.procedure$ LIKE '%ITEM%' AND args.argument LIKE '%LEAD_TIME_LOT_SIZE%' ORDER BY object_name, procedure$

There's a very good chance that an API with the parameter 'LEAD_TIME_LOT_SIZE' will be the one we are looking for. You can use this approach with any API search.

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. 2. 3. 4. p_record_version_number No status parameter No messages parameters 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 neverthe-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: API Wizard and Oracle APIs

API Wizard, the Oracle EBS Productivity Platform, is a software product built for Oracle EBS which is used to greatly streamline data entry, data updating, and reporting by providing an intuitive and efficient Microsoft Excel user interface to any business process. While the user interface is Excel, the backbone is a highly robust Oracle engine that communicates with the database and brokers the API calls. API Wizard Excel templates for processing any type of Oracle EBS data are generated using a sophisticated and streamlined integrated development environment which works with any public API (or, in fact, any pl/sql package.procedure) or open interface with no programming. Within minutes of selecting an API, you can have a fully functional, bi-directional, user friendly Excel interface for a business process. Once generated, these processes can be provisioned to appropriate EBS responsibilities. API Wizard works dynamically with any API by introspecting the Oracle data dictionary. It can work with public APIs, private APIs, and your own custom APIs and pl/sql programs without programming. You simply tell API Wizard the name of the API or package.procedure you want to work with and it exposes the API parameters. Next, you perform a GUI point-and-click configuration to select the parameters to include and their positioning in the template. In a few minutes, you'll have a completed configuration and you can simply press a button to build your Excel template. It's now ready for use. In addition to data entry and updating via APIs, API Wizard provides also provides a robust reporting package which can be used to run SQL-based reports, used for traditional reporting, drilldown reporting, extracting data for update, driving pivot tables and graphs, used in LOVs, etc. API Wizard saves Oracle users time because the Excel templates are exponentially faster (and more user-friendly) than working through Oracle forms. API Wizard saves IT time because it is, hands-down, the most efficient and easiest development environment in the entire Oracle EBS market. By leveraging Oracle's APIs, open interfaces, security, and governance rules, API Wizard saves time and provides value for anyone who works with Oracle EBS. For more information about API Wizard, please visit our website at: www.api-wizard.com.

Working Effectively with Oracle's Public APIs

20

Chapter 7: 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

21