Desktop Integrator - A webADI Introduction

Introduction :

For single records transaction Oracle suggest to use the application and
provides open interface and public APIs for bulk transaction.

webADI is another strong feature provided by Oracle for bulk operations,
which allows user to provide input in MS application (Word or Excel..etc).

Why WebADI ? :

It requires technical expertise for both interface and API usages.

For interface user should know to insert all transactional data into interface table and API needs transactional data to be imported in any portable format to server.

WebADI does not have such technical dependency as it is available to user as function and Launch desktop integrator (Excel) to feed transactional data.

This provides reporting option also.

How It works :

        For this one interface package required to do  initial validations.

Post it we can use any of options -   

1) Either insert all data into Interface Tables and run the Import
    Program Manually

2) Call API inside the interface program and do transactions directly  

Components  :  

1) Integrator  - Basic definition and includes user name, internal
                       name and application name

2) Interface   -  Most Important section , which directs data to flow (can
                       be either of Table or Procedure/Function type)

3) Content  -    This is required if webADI is being used for reporting
                       purpose also

4)  Upload    -   Controls the upload options

5)  Importer –  Definition of import options

6)  Layout  -     Attributes arrangement on excel

    

Responsibility - Desktop Integration Manager

Enable/Disable Concurrent Program Parameters

Requirement - Business need is to have multiple parameters but end user will be allowed to use one at a time. selection of any parameter, should disable others.  

Solution - Below is one possible option which provides the same behavior in other way.

This requires one additional parameter as Selection/Choice which will decide the enabled parameter.

There will be as many dummy (non displayed) parameters as required parameters in program. actual parameters will be dependent on respective dummy parameters.

Dummy parameters will be dependent on selection parameters and hold values based on selection.

Example - User requires 2 parameters supplier number and name to be available on one report and only one should be selected at time. So the requirement was to make other disable. dependent parameters has limitations and it cannot flow bottom to top. we can achieve this by introducing one selection parameter, which can hold 2 values -

1)      Name – Supplier Name

2)      Number – Supplier Number

Initially both Supplier Number and Name range parameter will be disabled.

 

Selection = Name , will enable supplier Name parameter range.

Selection = Number , will enable supplier Number parameter range.

Implementation – Create 3 dummy parameter (1 displayable and 2 non displayable).

           

Parameter	Value Set	Enable	Display
Test1	VS0	Y	Y
Test2	VS1	Y	N
Test3	VS2	Y	N

Value Set - VS0, will hold below values

Parameter Test2 and Test3 :

 

Default Value  select decode(:$FLEX$.VS0,'NUMBER','Y',NULL) from dual

Test3 will have similar definition.

Value Set =  VS2

Default Value  select decode(:$FLEX$.VS0,'NAME','Y',NULL) from dual

Now include the below condition for Number and Supplier Value set definition –

Supplier Number Value set  -   :$FLEX$.VS1='Y'

Supplier Name Value set     -   :$FLEX$.VS2='Y'