Conference rocks::dec_edi

3001.0. "AFS cache refresh" by ATYISA::LEBRUN () Fri Feb 07 1997 21:29

        I found a possible problem with fetching "AVAILABLE" documents in 
        that environment:
        
        - OPEN/VMS AXP 6.2
        - DECEDI 2.1D w/o patches
        - first installation of EDI on site with DEC/EDI
        - single EDIFACT translator and "afs_que_refresh" set to 
        default"06:00:00"
        
        Regarding the notes 2889.x and chiefly from Paul .1 and .6 I'd 
        position the occurence of events. We're in the initial first 
        test of documents with the mapper
        
        1) document #1 "AVAILABLE" has "FAILED"  on fetch due to a 
        failure in the mapper when it's been fetched for the first time
        
        2) document #2 has "FAILED" on fetch for the same reasons as 
        document #1
        
        3) We found the problem and we recompiled the mapping table
        
        4) document #3 arrived and has been fetched  "PURGEABLE"
        
        5) We decided to reset document #1 to "AVAILABLE"
        
        6) We did a fetch that didn't get document #1 "PURGEABLE". Why?
         We're on test and the customer is impatient to empty the live 
        database (for the first documents ... there)  
        
        QUESTION:
        
        1) The reason isn't it that the "RESET DOC" shouldn't take in 
        account the exact time when the RESET has been done rather than 
        the creation time of the document. That wouldn't make sense to 
        take it in account and i see another reason: it's very well 
        possible (we are in test) than the customer forgot (after 6 
        hours) the correct "maps" to succesfully fetch document #1 and #2
        
        2) That wouldn't hurt too much if it have been possible to 
        drop those "AVAILABLE" test documents and to forget them ? How?
        
        Regards,    
          
        

Hi,

1. Shutdown / Startup DEC/EDI
2. Reduce the refresh interval temporarily.

Mark

    It appears to be sensible to use the MODIFIED DATE rather than the
    CREATION DATE to select entries to add to the AFS queue, but it doesn't
    work. The CREATION DATE field is a unique index in the database, but
    the MODIFIED DATE is not, so there is only one entry for any given
    CREATION DATE, but there could be many entries for any MODIFIED DATE.
    The AFS entries need to be stored by unique index to avoid a huge
    overhead in retrieval, hence we use the CREATION DATE. 
    
    V3.2 will correct this problem, because it does not use the CREATION
    DATE to select entries to add to the AFS cache, only to retrieve the
    entries on a fetch.

        See Paul's .2 reply and say again than this matter worries us for 
        any kind of tests with a good reactivity.
        
        Another example is regarding the reprocess of documents just 
        separated after a "NO TRADING PARTNER PROFILE FOUND" and stuck in 
        the status "AWAITING_TRANSLATION" for ever until you 
        shutdown-restart DEC/EDI !!!
        
        That gives bad habits to customers and the question is to know 
        how to pass those documents asap to the translator !!! : AFS 
        queue refresh timer to be decreased ?  
        
        Regards,
        Jean 

    Re: .3
    
    Lowering the AFS cache refresh timer will have no effect on documents
    at AWAITING_TRANSLATION. The AFS cache only holds documents that have
    a status of AVAILABLE.