Results 1 to 10 of 10
  1. #1
    Member
    Join Date
    Sep 2007
    Location
    Chicago
    Posts
    20

    How to specify the Adapter mode

    It is just a matter of sending the key/value of (COMMAND, ADD/UPDATE) in the 'Update by MAP' protocol?

    I did this in a Java adapter but not sure how to do this in ARI.

    Thanks,
    Kal

  2. #2
    Administrator
    Join Date
    Jul 2006
    Location
    Milan
    Posts
    975
    Yes; if you are providing data for an item to be subscribed in COMMAND mode, then your "UD3" messages should contain
    a string field named "command", valued with one out of "ADD", "UPDATE" and "DELETE"
    and a string field named "key", valued with the current key,
    as well as the other fields.

    Dario

  3. #3
    Member
    Join Date
    Sep 2007
    Location
    Chicago
    Posts
    20
    Great! Thank you.

  4. #4
    Member
    Join Date
    Sep 2007
    Location
    Chicago
    Posts
    20
    Dario,

    Just to verify, is this a good format? This is for a view with 2 rows. I am trying add key1 and key2 rows.

    <timestamp>|UD3|S|<item name>|S|<ID>|B|<is snapshot>|S|key|S|key1|S|command|S|ADD|S|<field 1>|S|<value 1>|<field 2>|S|<value 2>|S|key|S|key2|S|command|S|ADD|S|<field 1>|S|<value 1>|<field 2>|S|<value 2>|

    Thanks
    -Kal

  5. #5
    Administrator
    Join Date
    Jul 2006
    Location
    Milan
    Posts
    975
    Kal,

    You need two distinct update lines for the two keys:
    <timestamp>|UD3|S|<item name>|S|<ID>|B|<is snapshot>|S|key|S|key1|S|command|S|ADD|S|<field 1>|S|<value 1>|<field 2>|S|<value 2>
    <timestamp>|UD3|S|<item name>|S|<ID>|B|<is snapshot>|S|key|S|key2|S|command|S|ADD|S|<field 1>|S|<value 1>|<field 2>|S|<value 2>
    This also holds when you are providing the initial snapshot.
    I have also removed the trailing '|' separator, though it is probably tolerated by the Proxy Adapter.

    Dario

  6. #6
    Member
    Join Date
    Sep 2007
    Location
    Chicago
    Posts
    20
    Dario,

    In case of a portfolio case, we don't know the number of entries. How can we add/remove multiple rows? I consider the item as a group of say, securities in a portfolio.

    Thanks
    Kal

  7. #7
    Administrator
    Join Date
    Jul 2006
    Location
    Milan
    Posts
    975
    Kal,

    I'm not sure I understand your requirements.
    With COMMAND mode, you cannot update several keys (i.e. rows) atomically: you must send update events for one key at a time.
    Only in case you are providing the initial snapshot, you can take advantage of the end-of-snapshot signal: your Data Adapter, after sending all lines related with the snapshot (that is, one ADD command, with <is snapshot> set as true, for each row which is included in the initial state) can send a
    <timestamp>|EOS|S|<item name>|S|<ID>
    line. In this way, your client custom code will receive a corresponding notification and this allows it to cache the snapshot lines and process them atomically when all of them have been collected (if this is your case, we can expand on this point).
    May you please provide an example of an operation which may not fit in this protocol?

    Dario

  8. #8
    Member
    Join Date
    Sep 2007
    Location
    Chicago
    Posts
    20
    Hi Dario,

    You explained it well, I now understand how the COMMAND mode works. I was a bit confused about how multiple will be grouped together.

    One additional question- How does the LS engine treats the order of the ADD/UPDATE? We are trying to do the sorting in the server side and not sure how to keep the order we send will be maintained through the LS engine to the page. Especially, the ADDs.

    Thanks,
    -Kal

  9. #9
    Administrator
    Join Date
    Jul 2006
    Location
    Milan
    Posts
    975
    Kal,

    Unfortunately, the COMMAND mode offers no guarantees that the sequence of keys, as received from the Data Adapter, is preserved when it reaches the Client. This is because the processing of the COMMAND mode is focused on
    • providing event filtering, when bandwidth or frequency constraints are set
    • keeping the current snapshot internally, so as to provide the correct snapshot to multiple subscribers of the same item

    and these features are not compatible with keeping the event sequence.

    In order to keep the event sequence, you should then lose the above benefits and subscribe to the item in "unfiltered" mode. In the middle of chapter 3.3 in "General Concepts.pdf" we show how this allows you to push ordered tables.
    I remind you that in this case the snapshot, though still kept by the Server, might not be correctly ordered; this means that, when a client subscribes to an item which is currently already subscribed to, the received snapshot might not be in the desired order.
    In order for the client to receive a correct snapshot, it should subscribe to a new item (i.e. use a different name to subscribe to the same data), so as to give rise to a new subscription towards the Data Adapter, which, in turn, can produce the current snapshot. But, in this case, the Data Adapter would have to manage two items with the same underlying data. In a portfolio use case this may be acceptable, as a very rare case (the same user watching its own portfolio in two different places).

    Dario

  10. #10
    Administrator
    Join Date
    Jul 2006
    Location
    Milan
    Posts
    975
    Sorry, I have to correct myself.
    Even with unfiltered dispatching, there is no guarantee that the initial snapshot received by the client is in the same order as the snapshot sent by the Data Adapter, even for the first subscriber.
    This is because, in the internal implementation, the start of the kernel-to-client flow is slightly deferred with respect to the start of the adapter-to-kernel flow. Hence, the very first events sent by the Data Adapter, rather than being directly forwarded to the client, are temporarily accumulated in the cached snapshot and this makes them lose the ordering.

    We can improve the management of this case in the next release update,
    so as to ensure that, at least, the first subscriber receives the events in the same order in which the Data Adapter sends them.

    For now, the best thing you can do is:
    • request the item by the client in "unfiltered" mode (as said before)
    • use different item names for different subscriptions of the same item (as said before)
    and, upon a subscription request to the Data Adapter:
    • send an EOS event as the first event
    • then send the snapshot in the form of regular updates
    • then send the real-time updates
    while at the client side:
    • still request the snapshot
    • check if snapshot events are received and cache them; as a consequence of what said before, this is still possible, but should hopefully be limited to a few events
    • upon reception of the end-of-snapshot notification, manually sort the cached snapshot events and finally process them
    • then process the forthcoming events normally, as they now keep the original ordering

    Dario

 

 

Similar Threads

  1. Data Adapter sample for COMMAND mode
    By Otake in forum Adapter APIs
    Replies: 5
    Last Post: October 18th, 2009, 08:09 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
All times are GMT +1. The time now is 01:44 PM.