This presentation is for informational purposes only and may not be incorporated into a contract or agreement.

The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decision. The development, release, and timing of any features or functionality described for Oracles products remains at the sole discretion of Oracle.

John RichardsonDirectorOracle CorporationThis presentation is for informational purposes only and may not be incorporated into a contract or agreement.

Web ADI:Extending the E-Business Suite with Desktop Applications

Session ID: S1847This presentation is for informational purposes only and may not be incorporated into a contract or agreement.

Today it is my pleasure to present how Web ADI is being used within the E-Business Suite to provide end-users with a familiar user interface.

AgendaDesktop IntegrationDevelopmentProduct RoadmapFor More InformationQuestions

Todays agenda will propose a definition of what is Desktop Integration. Then look at how this definition and understanding of this space has directed the movement from the client/server Applications Desktop Integrator, ADI, to its Web enabled successor Web ADI.

With this background in mind, Ill give you a brief look behind the scenes at how Development teams are using Web ADI today in the E-Business Suite to provide a desktop application front-end option to their customers.

We will then conclude with our current expected directions, and open for questions.

So what is Desktop Integration?

Desktop Integrationthe leveraging of Desktop Application functionality for performing E-business Suite tasks

The definition we developed for our review is Desktop Integration is the leveraging of Desktop Application functionality for performing E-Business Suite tasks.

But why would someone want to use a Desktop Application to do E-Business Suite tasks?

Desktop Integration MotivatorsProductivity Through the Use of a Familiar User InterfaceUtilization of a Desktop Application FeatureAddressing a Gap in the Functionality Provided by the IT Department

Looking around at any Business, you can find that there are three key motivators that will move someone to use a Desktop Application as an alternate front-end to the supplied application.

The first is productivity. If someone spends most of their working day in Excel, capitalizing on an end-users familiarity provides two benefits. Reduced training and Improved Workflow, If Im already comfortable and familiar with the desktop application in question, Im going to finish my tasks faster. I stay in the one application, I dont need to remember the set of alternate commands to complete the task, and Im not having to swap between several applications retyping data.

The second motivator recognizes that some Desktop Applications ship with very useful utilities, that can automate a manual process that could take hours. The capacity to bring data to the Desktop. Run the utility over the data. Then upload the data to the back end systems. Rather than manually making the changes can save time and frustration.

The last motivator is to use the development tools provided with a desktop application to address an end-users or groups need. Here the provided applications have not addressed their requirements and a solution is required to fill in the gap until the application is enhanced, or the requirements are unique or transitory in that business practices. It could be as simple as recording a macro to automate part of a data entry process, or producing a complex financials model with tens or hundreds of thousands of formulas and rules. Either way, the technology is there on our PCs and many people do take advantage of it to optimize their work day.

Desktop Integration ChallengesSecurityMovement of DataIntegrationMaintenanceAvailability of SkillsLegislative Compliance (Sarbanes-Oxley)

Incorporating Desktop Integration into a workflow with Enterprise systems however brings with it its own set of challenges.

How to provide the access to the individual uploading or downloading the data, without compromising security. Make sure that they dont see any records that they arent allowed to. Or to update records that they dont have permission to update. Connecting Excel to a database is easy. Create a database account and use ODBC to connect to the database. Data can now be moved between the desktop and the database. But there are no controls over this movement of data. Nothing stopping bad or incomplete data from being introduced into the database. Where checks are performed how to return this information to the end-user in a way that makes it simple to correct and then upload again.

The set of business rules defined in the code of the desktop application are based on the state of the database at a specific point in time. Change the functionality of the server side and the Integration between the two can be out of synchronization. In some cases additional functionality may be added, and everything will continue to work ok. In others the desktop application breaks until changes are applied to re-synchronize it with the back end.

This adds to the maintenance cost to ensure that the desktop code and the server side code are synchronized. The more complex the number of tools required, the more complex the desktop environment. PCs with many applications installed can begin to have conflicts between the versions of shared components. Even if the required number of applications is small, these conflicts can come from additional applications installed by the end-user.

Do staff have the right skill set to build the Desktop Application? Are they trained in the correct software development disciplines to produce code that will do the job and be maintainable?

Does the solution that you produce meet your Industry requirements or obligations? Sarbanes-Oxley is now being felt by the Financial Services sector. But other industries, such as Pharmaceuticals have had similar regulations in place for many years. Is the solution documented sufficiently to pass a compliance review?

Applications Desktop IntegratorGeneral Ledger, Assets, Reporting10 Year AnniversaryAddressed Security, Movement of Data, Legislative ComplianceGaps In Maintenance, Integration, Availability Of Skills

So how does ADI compare against these challenges? When we started development ten years ago some of these challenges didnt even exist. And have been created by changes in the industry as we were developing the Excel integration Wizards for General Ledger, Assets and Reporting.

On examination ADI matches up well against three of the challenges We cover Security requiring a valid Oracle user and responsibility to be provided before allowing access to functionality. Data security is maintained by incorporating these identifiers into the queries the users run, as per GL or FA business rules; Movement of Data is covered by performing validation checks against the data being provided returning any errors found for the end-user to address and upload again;and although not designed for we do provide a level of legislative compliance through the code being protected from change and permissions security allowing administrators to control access to who is allowed to create, upload, or import.

On the down side we do have gaps. Always a classic challenge is Maintenance, when you consider that excluding the Operating System, Office and Internet Explorer. ADI requires 100Mb of tech stack and its own files to be installed to work. Patches generally run around 10Mb, and in the worst case scenario installation requires, a Sneakernet, one or more staff running from one machine to the next with the ADI CD performing installations. Multiply that by 1,000 workstations, which some of our larger customers have, and its definitely a challenge. There is also the issue of end-users adding their own personalizations to their PC that dont play nicely with our tech stack.

There is always the potential for Integration to be an issue. Our timing may not be right for getting the equivalent functionality into ADI as has been supplied in GL or FA. Even if we do get the changes into ADI on time and released. There is still the co-ordination issue for the customer. How do I make sure the GL and ADI patch get rolled out to the database, middle-tier and clients at the same time? If one of the clients are missed, how much time is spent diagnosing a bug before synchronization is identified as the cause?

The number of wizards provided in ADI demonstrates our Availability of Skills has reached its limit. There has always been a plethora of other opportunities, but never the capacity in the ADI team to be able to learn another products functionality to be able to build and support a new Wizard, never enough resource on the product teams side to learn how to develop in Office.

Desktop Integration ObjectivesUse Internet Computing ArchitectureMinimize FootprintEnable Product Teams to Create SolutionsImprove PerformanceSupport Any Programmable Desktop ApplicationPreserve Existing Functionality

Several years ago when Applications moved to the Internet Computing Architecture we were set with the objective of moving ADI functionality away from Client Server to the Web.

Since it was necessary to re-architect Web ADI to meet this objective, it was decided to set some additional objectives to address the Desktop Integration challenges that ADI was not meeting.

We needed to minimize the amount of executables, resources and techstack on the desktop. By minimizing our footprint we reduce the maintenance cost as there are less components to conflict with each other, less components to configure.

We needed to change the approach to desktop application development. To enable the other product teams to use their available skills and functional knowledge to create Desktop Applications, not have to rely on the ADI team to convert their rules into Visual Basic code, or learn Visual Basic themselves.

We needed to look for opportunities to make ADI work faster. Especially across internet or slow network connections.

We needed to design ADI so that we can support other Office suites and applications. Not be so Excel focused.

We needed to migrate all of the ADI functionality to the Web.

Client Server Analysis

General LedgerJournal WizardBudget WizardReport WizardAnalysis WizardFixedAssetsCreate AssetsRecord Physical InventoryReport ManagerPublish ReportFormat Report OutputCommon ComponentsSecurityLayout DefinitionPersonalizationList of ValuesAutomationUploadValidationConcurrent ProgramsFeedbackDownload

With these objectives in mind we reviewed what functionality we have in ADI.Journal Wizard create GL Journal entries which are uploaded and imported ready for posting.Budget Wizard download Budget data for an organization, adjust the values and then upload and import back to general ledger.Report Wizard Create and maintain FSG reports in a spreadsheet interfaceAnalysis Wizard from a FSG report published to a spreadsheet, drill down on a value of interest to find the transactions that made up this value.Create Assets create Assets and upload them to Fixed Assets.Record Physical Inventory speed up your inventory process, by entering or importing text files for an inventory check into a spreadsheet, upload and then initiate the concurrent programs to compare with the actual assets and generate a comparison report.Publish Report Publish a FSG, Standard or Variable format report to Text, HTML or Excel, with the option of storing the report output in Report Manager for distribution.Format Report Output personalize the presentation of report output, by setting colors, formatting or even including graphics.

So what functionality is in common between these components. All of the features, save Format Report Output, require authentication before the user is allowed to use them.

Journals, Create Assets, and Inventory all allow the user to decide what columns that will be included in the layouts to fit their needs.Budget and Report Wizards download data, Assets and Inventory Wizards allow for a text file to be imported.

Journals, Report, Assets and Inventory wizards all have list of values for assisting data entry. From simple lists, to date pickers to Flexfields.

Budget Wizard includes several automation functions to make the work process simpler. Graphing, Filters, and Notes.All of the Wizards upload data, that data is Validated before it is inserted into the database. On a successful upload a Concurrent Program can be called continuing the processing of the data. If a validation failure occurs, Feedback is returned and displayed in the spreadsheet. Allowing for the failing rows to be identified and addressed.

The option to Set colors, set order of fields, zero padding for flexfields, to Personalize ADI.

If all of these Common Components could be moved into a framework they would provide an easy mechanism for teams like General Ledger, Fixed Assets and Report Manager product teams to build & ship their own Desktop Integration solutions.

Web ADIEnterprise Framework for Desktop IntegrationMeta Data Driven Client Side Application GeneratorZero Client InstallReduced Bandwidth Requirements to ClientProcessing Is Performed on the Middle-Tier

What developed from the analysis is Web ADI.

The core difference between ADI and Web ADI, is that Web ADI is now a framework for building Desktop Integration applications in the E-Business Suite. Designed with their availability of skills in mind, product teams are able to build fully functional desktop applications with a combination of meta-data and java. There is no requirement for these teams to know Visual Basic for Applications or the techstack requirements to get Office to interact with the Oracle Middle Tier or any of a hundred different nuances in the desktop environment. Product teams can now concentrate on building and shipping their functionality built in forms or OA Framework and ship a Desktop Integration solution in the same patch.

The metadata defined by the product team, and augmented by customer personalizations is used in the generation of the client side application. The resulting document has all of the dynamic interaction capabilities of ADI, custom generated to the users specification. With no redundant code being included, the size of the spreadsheet is small. This client side application is streamed down to the desktop, and only requires that the selected desktop application it has been generated for has been installed. There are no Web ADI components that need to be pre-installed and configured. You can build a PC from scratch. Install your preferred browser. Install Office. Signon to the E-Business Suite. Select to create a spreadsheet, and that spreadsheet will be created. Thats a Zero Client Install to use Web ADI. That means no requirement to patch the desktop to continue to use E-Business Suite desktop solutions. That design reduces the cost of maintenance.

The code that is included with the document at generation time, contains the functionality to generate the document, retrieve data, request a List of Values, upload, and process the results of the upload. All of the Business Rules defined by a product team remain on the middle-tier. Moving the bulk of the processing to the middle-tier, not to the desktop as was the case with ADI. This relocation changes the bandwidth usage of Desktop Integration solutions. There is no longer any need for multiple requests between the client and the database to validate each field. Now a single document for download and upload are sent between the client and the middle-tier. The better resourced and closer middle-tier handles all of the processing. For those of us lucky enough to have a desktop just as well resourced and sharing the same network bandwidth to the database as a middle-tier probably won't find Web ADI much faster. However for the rest of us. With older environments, working on slow networks or over dial-up. ADI will still be signing on by the time you've generated your spreadsheet.

Web ADIImplementations for Excel, Word and ProjectsEnhancements Benefit All UsersFirst Released January 2001, 1 Solution11i10 Released With Over 100 Solutions by 18 Teams

The Web ADI framework has also met its objective to support other Desktop Applications. Provided the desktop application has a development tool and is internet aware, code can be developed for Web ADI to work with that desktop application. This change in architecture to support Desktop Applications other than Excel can been seen today in the E-Business Suite. Two client server Desktop Integration applications: ADE shipped by HRMS to assist in the generation of letters in MS Word; Projects Accounting's Project Connect, which provides their customers with the ability to work with their data in MS Project. Both teams were able to utilize the Web ADI framework to move off their client server implementations and deliver web based solutions to their customers. We have looked beyond the Microsoft world. In conjunction with engineers at Sun Microsystems we have researched and confirmed that we can integrate Star Office with Web ADI. Currently other commitments are preventing us from starting work on a production version.

There are other advantages for a framework that generates the applications from meta-data. Functionality built into the framework on the request of one team becomes available to any other team on the same framework. Take Text Import for an example. In ADI text import was made available to the two Fixed Asset integrators. While this may have been useful to a Journal Wizard user, we never had the time to go back and retro fit this design. In Web ADI the functionality for text import was built into the framework for the Fixed Assets integrators. With some minor changes to meta data a General Ledger user who has Journals data from a third party system can use the General Ledger - Journals solution to import that text into their spreadsheet, check the data and upload.

When we started development, it was decided to keep it real. So the Journal Wizard replacement was developed as the functionality was built. Then shipped with Web ADI at the start of 2001.

Since that release Web ADI has continued to be improved to meet the needs of the product teams. In some cases the first time we hear from a product team is when they have encountered a problem or are suggesting an enhancement. So that four years later the latest 11i was released with 100 solutions. 25 times the number of equivalent solutions that were shipped in ADI. An effective confirmation of the strategy of moving to the framework to support the available skills.

Solution Product OwnersAdvanced Product CatalogAssetsFinancial IntelligenceGeneral LedgerHuman ResourcesIncentive CompensationInternal Controls ManagerProjectsPublic Sector Budgeting

Public Sector Financials InternationalPublic Sector HRPublic Sector PayrollSales OfflineStudent SystemsTerritoriesTrade ManagementTraining AdministratorWeb Applications Desktop Integrator

For reference the 18 product teams are listed here.

During the show we had the opportunity to get some customer feedback. Based on this feedback we are working with these product teams to provide an overview of the 100 plus solutions and make this information from the Web ADI area on Oracle.com.

For participants outside of development, who are interested in having Oracle produce desktop application solutions for your business. Please contact the product team that owns the equivalent server side functionality to register your interest. The Web ADI team is interested in what youd like to do, so please let us know. But ultimately it is the product team in that particular function area that will make the decision.

Technology StackClient SideOffice 97 / 2000 / XP / 2003Internet Explorer, Netscape, Firefox, MozillaOracle Applications 11.5.3 or LaterOracle Self Service Framework Version 5.6E or LaterOracle 9iAS Release 1.0.2.2.2 Oracle 8.1 Database or Later

So lets have a review of our zero client install technology stack for Web ADI.

As you can see the Web ADI requirements arent different from ADI. Web ADI can work with all versions of Office that have been released.

We are also compatible with any browser supported by the E-Business Suite. Earlier versions of Web ADI only supported Internet Explorer, but we were able to change that when we released the Patchset D version of Web ADI.

On the Middle-Tier and Database side there is nothing specific to Web ADI required. We will work on release 11.5.3 or later. And we do require Self Service 5.6E or later. Web ADI does not have any pre-requisites in 11i that force anyone to the latest release of techstack components.

This will change in Release 12. The Web ADI framework will start shipping as part of ATG in release 12. The key change is that there will be no need to be separately applying Web ADI patchsets as they will be included as part of the ATG PF.

D E M O N S T R A T I O NWeb ADI in Action

Superior Ownership Experience

Integrated WorkflowSecure CommunicationProduct Enhancements SynchronizedLower Total Cost Of OwnershipBusiness Rules Protected From Modification

Part Of, Looks Like, & Works Like an E-business Suite Product

A product team implementing functionality with Web ADI delivers a Superior Ownership Experience to their customers.

The transition from the browser based flows to the desktop applications is integrated, in some cases the end-user clicks on a button and they are viewing the data they work with in a spreadsheet.

The access to the functionality is protected by authentication. This same authentication is also incorporated into the download of data, only allowing the end-user to view the information they have permission for. Any accidental or malicious attempts to send bad data are protected through validation.

Changes to product functionality can now be synchronized to include the desktop application functionality. No second round of patching or co-ordination is required to keep the functionality working across the desktop, middle-tier and database.

Which leads to a lower total cost of ownership. The patches or new releases no longer require a sneaker net to be employed to be deployed. No more techstack conflicts between ADI and the other applications installed on the desktop.

Legislatively, all of the Business rules that protect the display of data to the end-user and the permission to update the base tables are all stored safely on the middle-tier and share the same functionality of the equivalent form or page.

A product team implementing functionality with Web ADI delivers a Superior Ownership Experience to their customers. Their solutions are shipped as part of the EB Suite Product, they look like an EB Suite product not just a collection of numbers and strings dumped into Excel, and they work like an EB Suite product with the same business rules and behaviors of their web based counterparts.

DevelopmentA Solution For Delivering Interactive Desktop Applications Without Needing Microsoft Tech Stack SkillsFaster to MarketLower Maintenance CostBasics are implemented using Meta-dataAdvanced Functionality using Java Extensibility

Id now like to change gears, and give everyone a feel for just how E-Business Suite product teams are using the Web ADI framework to deliver Desktop Applications.

I do apologize for this section. As some will consider this a huge tease showing capability that isnt available for general consumption outside of development. However during the demonstration hopefully you will see that the framework is at a point right now that is fine for internal consumption, but not at an appropriate level of sophistication to allow for a supportable tool. We would also like to see this happen but no date has been set for availability.

To restate. One of the goals in developing the Web ADI framework was to provide the means for product teams to deliver Desktop Application functionality without having to acquire a Microsoft skillset. Capitalizing on the existing skill set, not the skill set required by the desktop application and utilizing existing resource has its advantages. Functionality that is developed for the Web and for the Desktop by developers that dont have to change languages and technology stacks have the option of reusing code rather than re-inventing the wheel, bringing a solution to market faster. Issues found only need to be fixed in one location, not several.

The core definition of the solution is implemented by defining meta data in the Web ADI repository. This meta data defines the structure of the interface Web ADI uploads the data to; the source of where to retrieve data from; properties about the columns, like are they mandatory, do they have a list of values, are they validated before uploading; and whether a concurrent program should be run after a successful upload, to mention a few attributes. Anyone with a copy of SQL*Plus and functional knowledge of the interface they are working with can build a sophisticated solution.

There are limits to our ability to anticipate the needs of a product team, or to represent business rules through meta-data. For these scenarios a product team has the option of developing their own java code to implement their requirements.

TechnicalAny Product In E-Business Suite That Requires A Full Cycle Workflow For Their Product Can Be Integrated With Web ADIUpload to PL/SQL, Open Interfaces, Base Tables, JavaDownload from Java, SQL, Text ImportConcurrent Manager Support for Import ProgramsSingle Sign on CompliantJava Framework Includes Many Factory Patterns To Allow Easy Adaptation With Other Java Frameworks

Weve built a substantial level of functionality into Web ADI. So this slide is only covering the high-level of Web ADIs capabilities. An accurate definition of the capabilities would take more time than I have been allocated today.

The focus of Web ADI is to get data into the E-Business Suite. Web ADI can upload to PL/SQL procedures, Tables and Java. Generally the preference of the product teams is to use their pre-defined interfaces.

The options for bringing data into a document include Text Import, pre-defined SQL, and Java. Teams can use meta data for the SQL and Java options to define the additional questions needed to produce the query that will return the information the user needs.

For additional processing after a successful upload teams have the option of calling PL/SQL procedures or starting Concurrent programs. Further simplifying their end-users workflow.

All of this is within the boundaries of Applications Security. For authentication Web ADI calls the same functionality as all other products do. If Single Sign On is implemented, Web ADI is authenticated through that mechanism. The latest versions of Web ADI have linked each Desktop Integration solution to its equivalent Forms or OA Framework functionality. Reducing the administrative load. If a user already has access to the server side functionality, they have access to its Desktop equivalent.

The Java framework enables a powerful capacity to integrate functionality. Whether its plugging in our own default components, or calling out to code implemented by another team. The framework is flexible enough to allow some teams to create their own desktop application generation code, and are using their own upload code to generate and process the data from an industry standard XML format.

Architecture

The Web ADI architecture. As you can see a classic n-tiered design. The core of the architecture is the Browser or Desktop Application making and receiving calls through the HTTP Server to one of five Services. These services then make calls to the Database tier or to a product teams java through the java extensibility. The database tier is where the Web ADI Meta Data repository is stored.

Lets follow a typical user flow.

The user is signed into Oracle Applications in the browser. They click on a link that calls the Application Service showing all or part of the Create Document Page Flow that we saw earlier. Once all of the required information for generating a Desktop Application document has been supplied the Application Service calls off to the Document Service to start the creation process. A document is transferred to the desktop opening the desktop application. Once generation is complete a call may be made to the Download service to retrieve any data that will be displayed in the document.

Once in the document, the user can start working with the data. Performing Data Entry, referencing too and from other documents. Where a List of Values has been enabled, calls are made to the component service to display and return data. The download service can be called again to refresh the data. When ready, the Upload service is called, passing the upload parameters and the data from the sheet encoded in an XML document, where it is processed, validated and uploaded into the database.

D E M O N S T R A T I O NBuilding a Solution

As promised I would now like demonstrate the creation of a Web ADI solution against an Open Interface Table. For comparison I will use the GL_INTERFACE table. This demonstration will not involve any java. Just a single SQL script.

To build this I have a SQL script already prepared. As you can see the script contains a number of variables and three calls to PL/SQL procedures and some output messages.

Before I run the script I will need to supply a several values.As this is the GL_INTERFACE table I will supply General Ledgers Application ID 101I know my User ID is 1318I now need an unique identifier for this solution. To prove that this isnt a canned demo would someone from the audience, who doesnt work for Oracle, like to suggest a Name for our solution?[Enter variation of Name for Object_Code and Integrator User Name]

Now we need the name of the table we are working against, GL_INTERFACE and a user name General Ledger Journals Open Interface Table.

Set P_ALL_COLUMNS to FALSE

Now we are set to Run the script.

Script runs. Walkthrough the Create Document Page Flow and view the created sheet. Enter in data, upload. Then view the data in the table.

NEW.SQL ScriptSET SERVEROUTPUT ON;DECLARE P_INTEGRATOR_CODE VARCHAR2(30); P_INTERFACE_CODE VARCHAR2(30); P_LAYOUT_CODE VARCHAR2(30);

P_APPLICATION_ID NUMBER(15); P_OBJECT_CODE VARCHAR2(20); P_INTEGRATOR_USER_NAME VARCHAR2(240); P_LANGUAGE VARCHAR2(4); P_SOURCE_LANGUAGE VARCHAR2(4); P_USER_ID NUMBER(15); P_INTERFACE_TABLE_NAME VARCHAR2(50); P_INTERFACE_USER_NAME VARCHAR2(240); P_FORCE BOOLEAN; P_ALL_COLUMNS BOOLEAN;

BEGIN -- Define Constants P_APPLICATION_ID := 101; -- Application ID of the product that will -- own this Integrator P_LANGUAGE := 'US'; P_SOURCE_LANGUAGE := 'US'; P_USER_ID := 1318; -- Applications Database User ID that owns -- this Integrator

-- Set Solution Indentifier P_OBJECT_CODE := 'OOW_JOURNALS'; -- Object Code is used to generate the codes -- for Integrator, Interface and Layout

-- Set values for creating the Integrator P_INTEGRATOR_USER_NAME := 'OpenWorld - Journals'; -- Name of the Integrator that will be -- displayed in the User Interface

-- Set values for creating an Interface P_INTERFACE_TABLE_NAME := 'GL_INTERFACE'; -- Name of the Database table that data from -- the desktop application will be uploaded to. P_INTERFACE_USER_NAME := 'General Ledger Journals Open Interface'; -- Name of the table that will be displayed in -- the User Interface

-- Set values for creating a default Layout P_FORCE := FALSE; -- When TRUE - all existing layout data will -- be removed before recreating. Set to FALSE -- as there will be no layout data at this point P_ALL_COLUMNS := FALSE; -- All columns will be included in the layout -- when TRUE (otherwise only required columns -- are included) BNE_INTEGRATOR_UTILS.CREATE_INTEGRATOR (P_APPLICATION_ID, P_OBJECT_CODE, P_INTEGRATOR_USER_NAME, P_LANGUAGE, P_SOURCE_LANGUAGE, P_USER_ID, P_INTEGRATOR_CODE);

BNE_INTEGRATOR_UTILS.CREATE_INTERFACE_FOR_TABLE (P_APPLICATION_ID, P_OBJECT_CODE, P_INTEGRATOR_CODE, P_INTERFACE_TABLE_NAME, P_INTERFACE_USER_NAME, P_LANGUAGE, P_SOURCE_LANGUAGE, P_USER_ID, P_INTERFACE_CODE);

BNE_INTEGRATOR_UTILS.CREATE_DEFAULT_LAYOUT(P_APPLICATION_ID, P_OBJECT_CODE, P_INTEGRATOR_CODE, P_INTERFACE_CODE, P_USER_ID, P_FORCE, P_ALL_COLUMNS, P_LAYOUT_CODE);

COMMIT;

-- Results DBMS_OUTPUT.PUT_LINE('Integrator Code - ' || P_INTEGRATOR_CODE || '.'); DBMS_OUTPUT.PUT_LINE('Interface Code - ' || P_INTERFACE_CODE || '.'); DBMS_OUTPUT.PUT_LINE('Layout Code - ' || P_LAYOUT_CODE || '.');

END;/

Product Roadmap ADI Migration

Migration of ADI to the Web is always a topic of interest.

In the top table is the functionality that has been fully migrated to the Web. The bottom table, functionality that is in progress.

As I mentioned Journal Wizard has been migrated and shipped with Web ADI since 2001. In Release 12, General Ledger will be shipping the Journals solution as part of their product, and it will no longer be shipped with Web ADI.

The two Fixed Assets Integrators, Create Assets and Record Physical Inventory were shipped by Fixed Assets as part of the Financials Family Pack G.

The functionality to submit and publish FSG, Standard, and Variable format reports was incorporated into Patchset G of Report Manager. Consistent publishing enhancement requests always revolved around the requirement to have PCs dedicated to monitoring requests and then publishing. Why couldnt the processing and publishing be pushed up to the more powerful servers? This has been done. All of the processing and publishing of reports are handled on the servers. When complete the finished reports are stored in the Report Manager repository and can be viewed on demand. Links can be setup for users to retrieve these reports, and using the new format reports tool shown in the demonstration earlier. Each set of users can have a different formatted report output for the same stored report.

The remaining three wizards, Budget, Report and Analysis are in development right now. With code completion expected for the end of the year. Once we have completed development these will be handed off to GL for shipping. At this point we do not have release vehicles in mind for these features. Announcements will be made through appropriate channels once this is known.

Product Roadmap Web ADIRelease 12 Web ADI Shipping With ATG Family PackLayout Definition EnhancementsFormulasGraphsMultiple SheetsFusionTighter Integration with products

Being a framework occasionally leaves you with little to talk about that end-users can see. Leaving us to rely on the other product teams to use the functionality in their products and take the glory.

For Release 12 we have built a number of improvements that when available will be noticeable across all integrators. The IT Department will notice that there is no longer a separate Web ADI patch and if they look and read the documentation they will notice that we will be included with the ATG Family Pack. Reducing the number of patches that they are required to apply. One patch is always better than two.

A number of enhancements to the layout definition flow have been taken on board. With features including the re-ordering of columns, setting the width of columns, controlling the spanning of the header and context, and controlling the colors used in the spreadsheet among other features.

Some customers and product teams already define formulas in the layout definition page today using default values. But they are fragile and can break if additional columns are added. In Release 12 formulas can be defined that are not affected by any layout changes.

Graphing may also become available for some Integrators. This functionality will need to be enabled by the product team. As it may not be relevant to graph the data in some spreadsheets. For those that do, you will find the capability to have a graph automatically generated at the same time as the spreadsheet is created. Or to manually create the graph from a range of cells from the Oracle menu.

The most impressive feature of all is that we have broken the 64,000 row limit in Excel. This has long been a limit that we havent been able to beat. But download more than 64,000 rows in Release 12 and the remaining rows will move over on to the next worksheet. Our own production instance has over 7 million code combinations for budgeting. So if our finance people are prepared to wait they can download all of those rows, creating around 110 worksheets in the same workbook. Change the rows they need to change and upload all of the changed rows with one upload command. The creation of subsequent worksheets can be triggered deliberately and some product teams are planning on using this to create a worksheet for each organizational unit or some other logical grouping.

Looking forward. We will be researching ways of reducing the work that product teams need to complete to create Desktop Integration solutions.

ADI - Current ReleasesADI 7.2 Terminal ReleasePatch 396610111i10 DVD PackElectronic Delivery (edelivery.oracle.com)ADI 7.2 Rollup Patch 3Patch 4444037

The latest release of ADI is 7.2. Which shipped with enhancements toEnable Drill down to AX Subledger detailsProvided XBRL SupportCommand Line Submission and PublishingDatabase Definition using DBC filesThere was no change in the techstack between this release and ADI 7.1. So there will be no conflicts post the installation.

Web ADI - Current ReleasesWeb ADI Patchset D Base 3218526Latest Patch 4636671Includes Support For All Browsers

The latest patchset release for Web ADI is Patchset D. Which is the release that included the support for all browsers.

A

Web ADI - Extending the E-Business Suite with Desktop Applications

Web ADI - Extending the E-Business Suite with Desktop Applications

Web ADI - Extending the E-Business Suite with Desktop Applications

Web ADI - Extending the E-Business Suite with Desktop Applications

Web ADI - Extending the E-Business Suite with Desktop ApplicationsToday it is my pleasure to present how Web ADI is being used within the E-Business Suite to provide end-users with a familiar user interface.Web ADI - Extending the E-Business Suite with Desktop ApplicationsTodays agenda will propose a definition of what is Desktop Integration. Then look at how this definition and understanding of this space has directed the movement from the client/server Applications Desktop Integrator, ADI, to its Web enabled successor Web ADI.

With this background in mind, Ill give you a brief look behind the scenes at how Development teams are using Web ADI today in the E-Business Suite to provide a desktop application front-end option to their customers.

We will then conclude with our current expected directions, and open for questions.

So what is Desktop Integration?Web ADI - Extending the E-Business Suite with Desktop ApplicationsThe definition we developed for our review is Desktop Integration is the leveraging of Desktop Application functionality for performing E-Business Suite tasks.

But why would someone want to use a Desktop Application to do E-Business Suite tasks?Web ADI - Extending the E-Business Suite with Desktop ApplicationsLooking around at any Business, you can find that there are three key motivators that will move someone to use a Desktop Application as an alternate front-end to the supplied application.

The first is productivity. If someone spends most of their working day in Excel, capitalizing on an end-users familiarity provides two benefits. Reduced training and Improved Workflow, If Im already comfortable and familiar with the desktop application in question, Im going to finish my tasks faster. I stay in the one application, I dont need to remember the set of alternate commands to complete the task, and Im not having to swap between several applications retyping data.

The second motivator recognizes that some Desktop Applications ship with very useful utilities, that can automate a manual process that could take hours. The capacity to bring data to the Desktop. Run the utility over the data. Then upload the data to the back end systems. Rather than manually making the changes can save time and frustration.

The last motivator is to use the development tools provided with a desktop application to address an end-users or groups need. Here the provided applications have not addressed their requirements and a solution is required to fill in the gap until the application is enhanced, or the requirements are unique or transitory in that business practices. It could be as simple as recording a macro to automate part of a data entry process, or producing a complex financials model with tens or hundreds of thousands of formulas and rules. Either way, the technology is there on our PCs and many people do take advantage of it to optimize their work day.Web ADI - Extending the E-Business Suite with Desktop ApplicationsIncorporating Desktop Integration into a workflow with Enterprise systems however brings with it its own set of challenges.

How to provide the access to the individual uploading or downloading the data, without compromising security. Make sure that they dont see any records that they arent allowed to. Or to update records that they dont have permission to update. Connecting Excel to a database is easy. Create a database account and use ODBC to connect to the database. Data can now be moved between the desktop and the database. But there are no controls over this movement of data. Nothing stopping bad or incomplete data from being introduced into the database. Where checks are performed how to return this information to the end-user in a way that makes it simple to correct and then upload again.

The set of business rules defined in the code of the desktop application are based on the state of the database at a specific point in time. Change the functionality of the server side and the Integration between the two can be out of synchronization. In some cases additional functionality may be added, and everything will continue to work ok. In others the desktop application breaks until changes are applied to re-synchronize it with the back end.

This adds to the maintenance cost to ensure that the desktop code and the server side code are synchronized. The more complex the number of tools required, the more complex the desktop environment. PCs with many applications installed can begin to have conflicts between the versions of shared components. Even if the required number of applications is small, these conflicts can come from additional applications installed by the end-user.

Do staff have the right skill set to build the Desktop Application? Are they trained in the correct software development disciplines to produce code that will do the job and be maintainable?

Does the solution that you produce meet your Industry requirements or obligations? Sarbanes-Oxley is now being felt by the Financial Services sector. But other industries, such as Pharmaceuticals have had similar regulations in place for many years. Is the solution documented sufficiently to pass a compliance review?Web ADI - Extending the E-Business Suite with Desktop ApplicationsSo how does ADI compare against these challenges? When we started development ten years ago some of these challenges didnt even exist. And have been created by changes in the industry as we were developing the Excel integration Wizards for General Ledger, Assets and Reporting.

On examination ADI matches up well against three of the challenges We cover Security requiring a valid Oracle user and responsibility to be provided before allowing access to functionality. Data security is maintained by incorporating these identifiers into the queries the users run, as per GL or FA business rules; Movement of Data is covered by performing validation checks against the data being provided returning any errors found for the end-user to address and upload again;and although not designed for we do provide a level of legislative compliance through the code being protected from change and permissions security allowing administrators to control access to who is allowed to create, upload, or import.

On the down side we do have gaps. Always a classic challenge is Maintenance, when you consider that excluding the Operating System, Office and Internet Explorer. ADI requires 100Mb of tech stack and its own files to be installed to work. Patches generally run around 10Mb, and in the worst case scenario installation requires, a Sneakernet, one or more staff running from one machine to the next with the ADI CD performing installations. Multiply that by 1,000 workstations, which some of our larger customers have, and its definitely a challenge. There is also the issue of end-users adding their own personalizations to their PC that dont play nicely with our tech stack.

There is always the potential for Integration to be an issue. Our timing may not be right for getting the equivalent functionality into ADI as has been supplied in GL or FA. Even if we do get the changes into ADI on time and released. There is still the co-ordination issue for the customer. How do I make sure the GL and ADI patch get rolled out to the database, middle-tier and clients at the same time? If one of the clients are missed, how much time is spent diagnosing a bug before synchronization is identified as the cause?

The number of wizards provided in ADI demonstrates our Availability of Skills has reached its limit. There has always been a plethora of other opportunities, but never the capacity in the ADI team to be able to learn another products functionality to be able to build and support a new Wizard, never enough resource on the product teams side to learn how to develop in Office.Web ADI - Extending the E-Business Suite with Desktop ApplicationsSeveral years ago when Applications moved to the Internet Computing Architecture we were set with the objective of moving ADI functionality away from Client Server to the Web.

Since it was necessary to re-architect Web ADI to meet this objective, it was decided to set some additional objectives to address the Desktop Integration challenges that ADI was not meeting.

We needed to minimize the amount of executables, resources and techstack on the desktop. By minimizing our footprint we reduce the maintenance cost as there are less components to conflict with each other, less components to configure.

We needed to change the approach to desktop application development. To enable the other product teams to use their available skills and functional knowledge to create Desktop Applications, not have to rely on the ADI team to convert their rules into Visual Basic code, or learn Visual Basic themselves.

We needed to look for opportunities to make ADI work faster. Especially across internet or slow network connections.

We needed to design ADI so that we can support other Office suites and applications. Not be so Excel focused.

We needed to migrate all of the ADI functionality to the Web.Web ADI - Extending the E-Business Suite with Desktop ApplicationsWith these objectives in mind we reviewed what functionality we have in ADI.Journal Wizard create GL Journal entries which are uploaded and imported ready for posting.Budget Wizard download Budget data for an organization, adjust the values and then upload and import back to general ledger.Report Wizard Create and maintain FSG reports in a spreadsheet interfaceAnalysis Wizard from a FSG report published to a spreadsheet, drill down on a value of interest to find the transactions that made up this value.Create Assets create Assets and upload them to Fixed Assets.Record Physical Inventory speed up your inventory process, by entering or importing text files for an inventory check into a spreadsheet, upload and then initiate the concurrent programs to compare with the actual assets and generate a comparison report.Publish Report Publish a FSG, Standard or Variable format report to Text, HTML or Excel, with the option of storing the report output in Report Manager for distribution.Format Report Output personalize the presentation of report output, by setting colors, formatting or even including graphics.

So what functionality is in common between these components. All of the features, save Format Report Output, require authentication before the user is allowed to use them.

Journals, Create Assets, and Inventory all allow the user to decide what columns that will be included in the layouts to fit their needs.Budget and Report Wizards download data, Assets and Inventory Wizards allow for a text file to be imported.

Journals, Report, Assets and Inventory wizards all have list of values for assisting data entry. From simple lists, to date pickers to Flexfields.

Budget Wizard includes several automation functions to make the work process simpler. Graphing, Filters, and Notes.All of the Wizards upload data, that data is Validated before it is inserted into the database. On a successful upload a Concurrent Program can be called continuing the processing of the data. If a validation failure occurs, Feedback is returned and displayed in the spreadsheet. Allowing for the failing rows to be identified and addressed.

The option to Set colors, set order of fields, zero padding for flexfields, to Personalize ADI.

If all of these Common Components could be moved into a framework they would provide an easy mechanism for teams like General Ledger, Fixed Assets and Report Manager product teams to build & ship their own Desktop Integration solutions.Web ADI - Extending the E-Business Suite with Desktop ApplicationsWhat developed from the analysis is Web ADI.

The core difference between ADI and Web ADI, is that Web ADI is now a framework for building Desktop Integration applications in the E-Business Suite. Designed with their availability of skills in mind, product teams are able to build fully functional desktop applications with a combination of meta-data and java. There is no requirement for these teams to know Visual Basic for Applications or the techstack requirements to get Office to interact with the Oracle Middle Tier or any of a hundred different nuances in the desktop environment. Product teams can now concentrate on building and shipping their functionality built in forms or OA Framework and ship a Desktop Integration solution in the same patch.

The metadata defined by the product team, and augmented by customer personalizations is used in the generation of the client side application. The resulting document has all of the dynamic interaction capabilities of ADI, custom generated to the users specification. With no redundant code being included, the size of the spreadsheet is small. This client side application is streamed down to the desktop, and only requires that the selected desktop application it has been generated for has been installed. There are no Web ADI components that need to be pre-installed and configured. You can build a PC from scratch. Install your preferred browser. Install Office. Signon to the E-Business Suite. Select to create a spreadsheet, and that spreadsheet will be created. Thats a Zero Client Install to use Web ADI. That means no requirement to patch the desktop to continue to use E-Business Suite desktop solutions. That design reduces the cost of maintenance.

The code that is included with the document at generation time, contains the functionality to generate the document, retrieve data, request a List of Values, upload, and process the results of the upload. All of the Business Rules defined by a product team remain on the middle-tier. Moving the bulk of the processing to the middle-tier, not to the desktop as was the case with ADI. This relocation changes the bandwidth usage of Desktop Integration solutions. There is no longer any need for multiple requests between the client and the database to validate each field. Now a single document for download and upload are sent between the client and the middle-tier. The better resourced and closer middle-tier handles all of the processing. For those of us lucky enough to have a desktop just as well resourced and sharing the same network bandwidth to the database as a middle-tier probably won't find Web ADI much faster. However for the rest of us. With older environments, working on slow networks or over dial-up. ADI will still be signing on by the time you've generated your spreadsheet.Web ADI - Extending the E-Business Suite with Desktop ApplicationsThe Web ADI framework has also met its objective to support other Desktop Applications. Provided the desktop application has a development tool and is internet aware, code can be developed for Web ADI to work with that desktop application. This change in architecture to support Desktop Applications other than Excel can been seen today in the E-Business Suite. Two client server Desktop Integration applications: ADE shipped by HRMS to assist in the generation of letters in MS Word; Projects Accounting's Project Connect, which provides their customers with the ability to work with their data in MS Project. Both teams were able to utilize the Web ADI framework to move off their client server implementations and deliver web based solutions to their customers. We have looked beyond the Microsoft world. In conjunction with engineers at Sun Microsystems we have researched and confirmed that we can integrate Star Office with Web ADI. Currently other commitments are preventing us from starting work on a production version.

There are other advantages for a framework that generates the applications from meta-data. Functionality built into the framework on the request of one team becomes available to any other team on the same framework. Take Text Import for an example. In ADI text import was made available to the two Fixed Asset integrators. While this may have been useful to a Journal Wizard user, we never had the time to go back and retro fit this design. In Web ADI the functionality for text import was built into the framework for the Fixed Assets integrators. With some minor changes to meta data a General Ledger user who has Journals data from a third party system can use the General Ledger - Journals solution to import that text into their spreadsheet, check the data and upload.

When we started development, it was decided to keep it real. So the Journal Wizard replacement was developed as the functionality was built. Then shipped with Web ADI at the start of 2001.

Since that release Web ADI has continued to be improved to meet the needs of the product teams. In some cases the first time we hear from a product team is when they have encountered a problem or are suggesting an enhancement. So that four years later the latest 11i was released with 100 solutions. 25 times the number of equivalent solutions that were shipped in ADI. An effective confirmation of the strategy of moving to the framework to support the available skills.Web ADI - Extending the E-Business Suite with Desktop ApplicationsFor reference the 18 product teams are listed here.

During the show we had the opportunity to get some customer feedback. Based on this feedback we are working with these product teams to provide an overview of the 100 plus solutions and make this information from the Web ADI area on Oracle.com.

For participants outside of development, who are interested in having Oracle produce desktop application solutions for your business. Please contact the product team that owns the equivalent server side functionality to register your interest. The Web ADI team is interested in what youd like to do, so please let us know. But ultimately it is the product team in that particular function area that will make the decision.

Web ADI - Extending the E-Business Suite with Desktop ApplicationsSo lets have a review of our zero client install technology stack for Web ADI.

As you can see the Web ADI requirements arent different from ADI. Web ADI can work with all versions of Office that have been released.

We are also compatible with any browser supported by the E-Business Suite. Earlier versions of Web ADI only supported Internet Explorer, but we were able to change that when we released the Patchset D version of Web ADI.

On the Middle-Tier and Database side there is nothing specific to Web ADI required. We will work on release 11.5.3 or later. And we do require Self Service 5.6E or later. Web ADI does not have any pre-requisites in 11i that force anyone to the latest release of techstack components.

This will change in Release 12. The Web ADI framework will start shipping as part of ATG in release 12. The key change is that there will be no need to be separately applying Web ADI patchsets as they will be included as part of the ATG PF.Web ADI - Extending the E-Business Suite with Desktop Applications

Web ADI - Extending the E-Business Suite with Desktop ApplicationsA product team implementing functionality with Web ADI delivers a Superior Ownership Experience to their customers.

The transition from the browser based flows to the desktop applications is integrated, in some cases the end-user clicks on a button and they are viewing the data they work with in a spreadsheet.

The access to the functionality is protected by authentication. This same authentication is also incorporated into the download of data, only allowing the end-user to view the information they have permission for. Any accidental or malicious attempts to send bad data are protected through validation.

Changes to product functionality can now be synchronized to include the desktop application functionality. No second round of patching or co-ordination is required to keep the functionality working across the desktop, middle-tier and database.

Which leads to a lower total cost of ownership. The patches or new releases no longer require a sneaker net to be employed to be deployed. No more techstack conflicts between ADI and the other applications installed on the desktop.

Legislatively, all of the Business rules that protect the display of data to the end-user and the permission to update the base tables are all stored safely on the middle-tier and share the same functionality of the equivalent form or page.

A product team implementing functionality with Web ADI delivers a Superior Ownership Experience to their customers. Their solutions are shipped as part of the EB Suite Product, they look like an EB Suite product not just a collection of numbers and strings dumped into Excel, and they work like an EB Suite product with the same business rules and behaviors of their web based counterparts.Web ADI - Extending the E-Business Suite with Desktop ApplicationsId now like to change gears, and give everyone a feel for just how E-Business Suite product teams are using the Web ADI framework to deliver Desktop Applications.

I do apologize for this section. As some will consider this a huge tease showing capability that isnt available for general consumption outside of development. However during the demonstration hopefully you will see that the framework is at a point right now that is fine for internal consumption, but not at an appropriate level of sophistication to allow for a supportable tool. We would also like to see this happen but no date has been set for availability.

To restate. One of the goals in developing the Web ADI framework was to provide the means for product teams to deliver Desktop Application functionality without having to acquire a Microsoft skillset. Capitalizing on the existing skill set, not the skill set required by the desktop application and utilizing existing resource has its advantages. Functionality that is developed for the Web and for the Desktop by developers that dont have to change languages and technology stacks have the option of reusing code rather than re-inventing the wheel, bringing a solution to market faster. Issues found only need to be fixed in one location, not several.

The core definition of the solution is implemented by defining meta data in the Web ADI repository. This meta data defines the structure of the interface Web ADI uploads the data to; the source of where to retrieve data from; properties about the columns, like are they mandatory, do they have a list of values, are they validated before uploading; and whether a concurrent program should be run after a successful upload, to mention a few attributes. Anyone with a copy of SQL*Plus and functional knowledge of the interface they are working with can build a sophisticated solution.

There are limits to our ability to anticipate the needs of a product team, or to represent business rules through meta-data. For these scenarios a product team has the option of developing their own java code to implement their requirements.Web ADI - Extending the E-Business Suite with Desktop ApplicationsWeve built a substantial level of functionality into Web ADI. So this slide is only covering the high-level of Web ADIs capabilities. An accurate definition of the capabilities would take more time than I have been allocated today.

The focus of Web ADI is to get data into the E-Business Suite. Web ADI can upload to PL/SQL procedures, Tables and Java. Generally the preference of the product teams is to use their pre-defined interfaces.

The options for bringing data into a document include Text Import, pre-defined SQL, and Java. Teams can use meta data for the SQL and Java options to define the additional questions needed to produce the query that will return the information the user needs.

For additional processing after a successful upload teams have the option of calling PL/SQL procedures or starting Concurrent programs. Further simplifying their end-users workflow.

All of this is within the boundaries of Applications Security. For authentication Web ADI calls the same functionality as all other products do. If Single Sign On is implemented, Web ADI is authenticated through that mechanism. The latest versions of Web ADI have linked each Desktop Integration solution to its equivalent Forms or OA Framework functionality. Reducing the administrative load. If a user already has access to the server side functionality, they have access to its Desktop equivalent.

The Java framework enables a powerful capacity to integrate functionality. Whether its plugging in our own default components, or calling out to code implemented by another team. The framework is flexible enough to allow some teams to create their own desktop application generation code, and are using their own upload code to generate and process the data from an industry standard XML format.

Web ADI - Extending the E-Business Suite with Desktop ApplicationsThe Web ADI architecture. As you can see a classic n-tiered design. The core of the architecture is the Browser or Desktop Application making and receiving calls through the HTTP Server to one of five Services. These services then make calls to the Database tier or to a product teams java through the java extensibility. The database tier is where the Web ADI Meta Data repository is stored.

Lets follow a typical user flow.

The user is signed into Oracle Applications in the browser. They click on a link that calls the Application Service showing all or part of the Create Document Page Flow that we saw earlier. Once all of the required information for generating a Desktop Application document has been supplied the Application Service calls off to the Document Service to start the creation process. A document is transferred to the desktop opening the desktop application. Once generation is complete a call may be made to the Download service to retrieve any data that will be displayed in the document.

Once in the document, the user can start working with the data. Performing Data Entry, referencing too and from other documents. Where a List of Values has been enabled, calls are made to the component service to display and return data. The download service can be called again to refresh the data. When ready, the Upload service is called, passing the upload parameters and the data from the sheet encoded in an XML document, where it is processed, validated and uploaded into the database.Web ADI - Extending the E-Business Suite with Desktop ApplicationsAs promised I would now like demonstrate the creation of a Web ADI solution against an Open Interface Table. For comparison I will use the GL_INTERFACE table. This demonstration will not involve any java. Just a single SQL script.

To build this I have a SQL script already prepared. As you can see the script contains a number of variables and three calls to PL/SQL procedures and some output messages.

Before I run the script I will need to supply a several values.As this is the GL_INTERFACE table I will supply General Ledgers Application ID 101I know my User ID is 1318I now need an unique identifier for this solution. To prove that this isnt a canned demo would someone from the audience, who doesnt work for Oracle, like to suggest a Name for our solution?[Enter variation of Name for Object_Code and Integrator User Name]

Now we need the name of the table we are working against, GL_INTERFACE and a user name General Ledger Journals Open Interface Table.

Set P_ALL_COLUMNS to FALSE

Now we are set to Run the script.

Script runs. Walkthrough the Create Document Page Flow and view the created sheet. Enter in data, upload. Then view the data in the table.

NEW.SQL ScriptSET SERVEROUTPUT ON;DECLARE P_INTEGRATOR_CODE VARCHAR2(30); P_INTERFACE_CODE VARCHAR2(30); P_LAYOUT_CODE VARCHAR2(30);

P_APPLICATION_ID NUMBER(15); P_OBJECT_CODE VARCHAR2(20); P_INTEGRATOR_USER_NAME VARCHAR2(240); P_LANGUAGE VARCHAR2(4); P_SOURCE_LANGUAGE VARCHAR2(4); P_USER_ID NUMBER(15); P_INTERFACE_TABLE_NAME VARCHAR2(50); P_INTERFACE_USER_NAME VARCHAR2(240); P_FORCE BOOLEAN; P_ALL_COLUMNS BOOLEAN;

BEGIN -- Define Constants P_APPLICATION_ID := 101; -- Application ID of the product that will -- own this Integrator P_LANGUAGE := 'US'; P_SOURCE_LANGUAGE := 'US'; P_USER_ID := 1318; -- Applications Database User ID that owns -- this Integrator

-- Set Solution Indentifier P_OBJECT_CODE := 'OOW_JOURNALS'; -- Object Code is used to generate the codes -- for Integrator, Interface and Layout

-- Set values for creating the Integrator P_INTEGRATOR_USER_NAME := 'OpenWorld - Journals'; -- Name of the Integrator that will be -- displayed in the User Interface

-- Set values for creating an Interface P_INTERFACE_TABLE_NAME := 'GL_INTERFACE'; -- Name of the Database table that data from -- the desktop application will be uploaded to. P_INTERFACE_USER_NAME := 'General Ledger Journals Open Interface'; -- Name of the table that will be displayed in -- the User Interface

-- Set values for creating a default Layout P_FORCE := FALSE; -- When TRUE - all existing layout data will -- be removed before recreating. Set to FALSE -- as there will be no layout data at this point P_ALL_COLUMNS := FALSE; -- All columns will be included in the layout -- when TRUE (otherwise only required columns -- are included) BNE_INTEGRATOR_UTILS.CREATE_INTEGRATOR (P_APPLICATION_ID, P_OBJECT_CODE, P_INTEGRATOR_USER_NAME, P_LANGUAGE, P_SOURCE_LANGUAGE, P_USER_ID, P_INTEGRATOR_CODE);

BNE_INTEGRATOR_UTILS.CREATE_INTERFACE_FOR_TABLE (P_APPLICATION_ID, P_OBJECT_CODE, P_INTEGRATOR_CODE, P_INTERFACE_TABLE_NAME, P_INTERFACE_USER_NAME, P_LANGUAGE, P_SOURCE_LANGUAGE, P_USER_ID, P_INTERFACE_CODE);

BNE_INTEGRATOR_UTILS.CREATE_DEFAULT_LAYOUT(P_APPLICATION_ID, P_OBJECT_CODE, P_INTEGRATOR_CODE, P_INTERFACE_CODE, P_USER_ID, P_FORCE, P_ALL_COLUMNS, P_LAYOUT_CODE);

COMMIT;

-- Results DBMS_OUTPUT.PUT_LINE('Integrator Code - ' || P_INTEGRATOR_CODE || '.'); DBMS_OUTPUT.PUT_LINE('Interface Code - ' || P_INTERFACE_CODE || '.'); DBMS_OUTPUT.PUT_LINE('Layout Code - ' || P_LAYOUT_CODE || '.');

END;/Web ADI - Extending the E-Business Suite with Desktop ApplicationsMigration of ADI to the Web is always a topic of interest.

In the top table is the functionality that has been fully migrated to the Web. The bottom table, functionality that is in progress.

As I mentioned Journal Wizard has been migrated and shipped with Web ADI since 2001. In Release 12, General Ledger will be shipping the Journals solution as part of their product, and it will no longer be shipped with Web ADI.

The two Fixed Assets Integrators, Create Assets and Record Physical Inventory were shipped by Fixed Assets as part of the Financials Family Pack G.

The functionality to submit and publish FSG, Standard, and Variable format reports was incorporated into Patchset G of Report Manager. Consistent publishing enhancement requests always revolved around the requirement to have PCs dedicated to monitoring requests and then publishing. Why couldnt the processing and publishing be pushed up to the more powerful servers? This has been done. All of the processing and publishing of reports are handled on the servers. When complete the finished reports are stored in the Report Manager repository and can be viewed on demand. Links can be setup for users to retrieve these reports, and using the new format reports tool shown in the demonstration earlier. Each set of users can have a different formatted report output for the same stored report.

The remaining three wizards, Budget, Report and Analysis are in development right now. With code completion expected for the end of the year. Once we have completed development these will be handed off to GL for shipping. At this point we do not have release vehicles in mind for these features. Announcements will be made through appropriate channels once this is known.Web ADI - Extending the E-Business Suite with Desktop ApplicationsBeing a framework occasionally leaves you with little to talk about that end-users can see. Leaving us to rely on the other product teams to use the functionality in their products and take the glory.

For Release 12 we have built a number of improvements that when available will be noticeable across all integrators. The IT Department will notice that there is no longer a separate Web ADI patch and if they look and read the documentation they will notice that we will be included with the ATG Family Pack. Reducing the number of patches that they are required to apply. One patch is always better than two.

A number of enhancements to the layout definition flow have been taken on board. With features including the re-ordering of columns, setting the width of columns, controlling the spanning of the header and context, and controlling the colors used in the spreadsheet among other features.

Some customers and product teams already define formulas in the layout definition page today using default values. But they are fragile and can break if additional columns are added. In Release 12 formulas can be defined that are not affected by any layout changes.

Graphing may also become available for some Integrators. This functionality will need to be enabled by the product team. As it may not be relevant to graph the data in some spreadsheets. For those that do, you will find the capability to have a graph automatically generated at the same time as the spreadsheet is created. Or to manually create the graph from a range of cells from the Oracle menu.

The most impressive feature of all is that we have broken the 64,000 row limit in Excel. This has long been a limit that we havent been able to beat. But download more than 64,000 rows in Release 12 and the remaining rows will move over on to the next worksheet. Our own production instance has over 7 million code combinations for budgeting. So if our finance people are prepared to wait they can download all of those rows, creating around 110 worksheets in the same workbook. Change the rows they need to change and upload all of the changed rows with one upload command. The creation of subsequent worksheets can be triggered deliberately and some product teams are planning on using this to create a worksheet for each organizational unit or some other logical grouping.

Looking forward. We will be researching ways of reducing the work that product teams need to complete to create Desktop Integration solutions.Web ADI - Extending the E-Business Suite with Desktop ApplicationsThe latest release of ADI is 7.2. Which shipped with enhancements toEnable Drill down to AX Subledger detailsProvided XBRL SupportCommand Line Submission and PublishingDatabase Definition using DBC filesThere was no change in the techstack between this release and ADI 7.1. So there will be no conflicts post the installation.Web ADI - Extending the E-Business Suite with Desktop ApplicationsThe latest patchset release for Web ADI is Patchset D. Which is the release that included the support for all browsers.Web ADI - Extending the E-Business Suite with Desktop Applications

Web ADI - Extending the E-Business Suite with Desktop Applications