Data Replication 2
Results 1 to 2 of 2

Thread: Setting up Adapters with the Same Name but Different Definition

  1. #1
    Join Date
    Sep 2006
    Posts
    233
    Rep Power
    10

    Setting up Adapters with the Same Name but Different Definition

    Sometimes you want to have adapters with the same name under different binding but you want each adapter to have its own definition. The normal behavior of AIS is to associate the same definition to adapters having the same name.

    In this article we describe how to give adapters with the same name a different definition under different bindings.

    In AIS, an adapter is set up in two steps:
    1. Adapter binding - in this step you give the adapter a name, select its type, provide various configuration data and optionally associate it with a specific definition name. If no definition name is given, an adapter definition with same name as the adapter is assumed.
    2. Adapter definition - in this step you specify the adapter metadata. This includes the adapter interactions as well as its input and output records. All adapter definitions are stored as named <adapter> documents in the SYS object store (NOS) and are shared between all bindings.


    The Attunity Studio up to version 5.1 does not support direct setup as discussed in this article and so a special procedure is needed for defining and editing adapters with the same name but different binding

    Suppose we have two bindings, PLANT_A and PLANT_B and we want to define an adapter called INVENTORY in each binding and make it so that each adapter get its own definition.

    The process of creating the two adapters is as follows:

    1. Create adapter INVENTORY_A under binding PLANT_A. Edit its metadata and see that it works as expected.
    2. Create adapter INVENTORY_B under binding PLANT_B. Edit its metadata and see that it works as expected.
    3. Open binding PLANT_A as XML, look for the 'adapter' element with the name 'INVENTORY_A' and change the name attribute to 'INVENTORY'. Make sure that the definition attribute remains 'INVENTORY_A'. Save the edit.
    4. Open binding PLANT_B as XML, look for the 'adapter' element with the name 'INVENTORY_B' and change the name attribute to 'INVENTORY'. Make sure that the definition attribute remains 'INVENTORY_B'. Save the edit.
    5. Recycle the workspaces that use these binding and refresh the machine tree in the design perspective.
    6. At this point we have two adapters called 'INVENTORY' under both binding where in each binding the definition is different. The adapters are ready to be used.


    In order to edit the adapter definition of one of the adapters (say, INVENTORY of binding PLANT_A), follow this procedure:

    1. Open binding PLANT_A as XML, look for the 'adapter' element with the name 'INVENTORY' and change the name attribute to 'INVENTORY_A'. Save the edit.
    2. Refresh the machine tree of binding PLANT_A in the design perspective.
    3. Perform any edits needed on the adapter INVENTORY_A.
    4. When done, open again the binding PLANT_A as XML and change back the name attrobute to 'INVENTORY'.
    5. Recycle the workspaces the PLANT_A binding and refresh the machine tree in the design perspective.


    Note: do not try to edit the adapters while they are called INVENTORY - Studio will try to use a non-existing INVENTORY definition.

    The following box shows how the binding and adapter definition would look in the scenario described above.
    PHP Code:
    <navobj version='5.1.0.99'>
        <
    binding name='PLANT_A'>
            <
    adapters name='PLANT_A'>
               <
    adapter name='INVENTORY' type='myType' definition='INVENTORY_A' &#8230; >
           
    </adapters>
       </
    binding>
       <
    binding name='PLANT_B'>
           <
    adapters name='PLANT_B'>
               <
    adapter name='INVENTORY' type='myType' definition='INVENTORY_B' &#8230; >
           
    </adapters>
       </
    binding>

        <!&
    #8212;Following are the adapter_def definitions -->
        
    <adapter name='INVENTORY_A' type='TuxedoQueue'>
            <
    adapterSpec bufferType='FML32' eventsHeader='true' eventsRecord='aud' eventsVariantField=''/>
            <
    schema noAlignment='true'>
                <
    record name='a_bumble_bee'>
                    &
    #8230;
                
    </record>
            </
    schema>
        </
    adapter>

        <
    adapter name='INVENTORY_B' type='TuxedoQueue'>
            <
    adapterSpec bufferType='FML32' eventsHeader='true' eventsRecord='aud' eventsVariantField=''/>
            <
    schema noAlignment='true'>
                <
    record name='an_evil_bumble_bee'>
                    &
    #8230;
                
    </record>
            </
    schema>
        </
    adapter>
    </
    navobj
    Last edited by DrorHarari; 03-26-2009 at 04:20 AM.
    By Dror Harari

    To Find Out more About Attunity Technology:
    Attunity
    or:
    Contact Us

  2. #2
    Join Date
    Sep 2006
    Posts
    233
    Rep Power
    10
    Minor clarification: it is possible to edit the adapter INVENTORY under binding PLANT_A directly without going through the rename process but in that case, one cannot test interactions. The described process works around this issue.
    By Dror Harari

    To Find Out more About Attunity Technology:
    Attunity
    or:
    Contact Us

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •