Topic
  • 5 replies
  • Latest Post - ‏2013-05-17T12:00:43Z by mark99
SystemAdmin
SystemAdmin
9855 Posts

Pinned topic Using More Than One Assembly Line For One Adapter Operation

‏2013-04-02T07:04:40Z |
I have a custom adapter with typical add, modify, delete, etc operations in it. Now I would like to use 2 versions of assembly Lines for Add Operation.

How to achieve it?
Updated on 2013-04-03T03:53:36Z at 2013-04-03T03:53:36Z by SystemAdmin
  • SystemAdmin
    SystemAdmin
    9855 Posts

    Re: Using More Than One Assembly Line For One Adapter Operation

    ‏2013-04-02T08:01:32Z  
    Why do you want to use 2 ALs ?

    First - you have to explain what your base requirement is - we are not able to help you if we do not understand your goal - just saying "I want this solution" does not help you - especially when the solution is not possible....

    Basically what you can do is either to spawn seperate ALs based on some criteria (using the AL FC) or implement one AL that takes care of the different cases.

    Another option is to have 2 versions running in different dispatchers.

    But what to choose (or you should some thing complete different) is impossible to judge from you question.

    HTH

    Regards
    Franz
  • SystemAdmin
    SystemAdmin
    9855 Posts

    Re: Using More Than One Assembly Line For One Adapter Operation

    ‏2013-04-02T09:54:26Z  
    Why do you want to use 2 ALs ?

    First - you have to explain what your base requirement is - we are not able to help you if we do not understand your goal - just saying "I want this solution" does not help you - especially when the solution is not possible....

    Basically what you can do is either to spawn seperate ALs based on some criteria (using the AL FC) or implement one AL that takes care of the different cases.

    Another option is to have 2 versions running in different dispatchers.

    But what to choose (or you should some thing complete different) is impossible to judge from you question.

    HTH

    Regards
    Franz
    Thanks for the reply Franz. Actually currently there is no practical requirement for such a scenario however I am curious to know that how can we quickly change the assembly lines with out changing the XMLs or adapter.

    According to your reply we can have 2 versions running in 2 different dispatchers, however when we import a service profile in TIM then LDAP stores the assembly line and later on provide it to the dispatcher when the operation is called for the first time, Dispatcher then cache that assembly line for subsequent requests, so even if we have 2 Dispatchers running, how can we have 2 different versions of assembly lines running on 2 dispatchers. I hope I am clear this time with my question. :)
  • yn2000
    yn2000
    1086 Posts

    Re: Using More Than One Assembly Line For One Adapter Operation

    ‏2013-04-02T14:45:48Z  
    Thanks for the reply Franz. Actually currently there is no practical requirement for such a scenario however I am curious to know that how can we quickly change the assembly lines with out changing the XMLs or adapter.

    According to your reply we can have 2 versions running in 2 different dispatchers, however when we import a service profile in TIM then LDAP stores the assembly line and later on provide it to the dispatcher when the operation is called for the first time, Dispatcher then cache that assembly line for subsequent requests, so even if we have 2 Dispatchers running, how can we have 2 different versions of assembly lines running on 2 dispatchers. I hope I am clear this time with my question. :)
    It does not matter how you twist it, it is a very bad idea to have two versions doing the same thing at the same place. Your proposal will not pass the Change Control Manager inspection, who is always (or maybe 'usually') strict with version control.

    Don't get me wrong. You can build a main AL that is controlling the other two ALs, but this type of design is not for version 'quickly change' purpose. ('quickly change' is faster than re-import profile, but slower than automatic parameter change)

    Rgds. YN.
  • SystemAdmin
    SystemAdmin
    9855 Posts

    Re: Using More Than One Assembly Line For One Adapter Operation

    ‏2013-04-03T03:53:36Z  
    • yn2000
    • ‏2013-04-02T14:45:48Z
    It does not matter how you twist it, it is a very bad idea to have two versions doing the same thing at the same place. Your proposal will not pass the Change Control Manager inspection, who is always (or maybe 'usually') strict with version control.

    Don't get me wrong. You can build a main AL that is controlling the other two ALs, but this type of design is not for version 'quickly change' purpose. ('quickly change' is faster than re-import profile, but slower than automatic parameter change)

    Rgds. YN.
    I agree with you yn. Franz's suggestion of conditional assembly line selection is the best approach.
  • mark99
    mark99
    26 Posts

    Re: Using More Than One Assembly Line For One Adapter Operation

    ‏2013-05-17T12:00:43Z  
    Thanks for the reply Franz. Actually currently there is no practical requirement for such a scenario however I am curious to know that how can we quickly change the assembly lines with out changing the XMLs or adapter.

    According to your reply we can have 2 versions running in 2 different dispatchers, however when we import a service profile in TIM then LDAP stores the assembly line and later on provide it to the dispatcher when the operation is called for the first time, Dispatcher then cache that assembly line for subsequent requests, so even if we have 2 Dispatchers running, how can we have 2 different versions of assembly lines running on 2 dispatchers. I hope I am clear this time with my question. :)

    You can use the following dispatcher parameter in the services.def

       <dispatcherParameter name="ALFileSystemPath" source= "erPosixALFileSystemPath"> 
       </dispatcherParameter>

    In that case dispatcher does not uses the ones stored in tim but thos on the filesystem

    you can then use 2 different verions on the filesystem of different TDI instances