Conference virke::mrmemo

    
    I think your customer definitely wants to convert to DDIF. This would
    ideally mean that all other gateways could handle the documents. 
    
    The way MRMEMO (and most other *current* versions of MR gateways) work, is
    that that they look for bodyparts of type DECBODY7 and regard them as
    DDIF files. Then CDA converter library routines are used to convert to
    whatever format is supported through the gateway. MRMEMO only supports
    text, so that's not very complicated. For the actual DDIF->Text
    conversion, MRMEMO uses a CDA Front-End converter
    DDIF$READ_DECBODY7.EXE, which we stole from the MRT/MRFAX team in
    Valbonne. This is merely a black box for us, but it seems to work OK.
    For WPSPLUS->Text conversions we use that old darling DCF (Document
    Conversion Facility). This package is also used in all current MR-Gateways.
    
    However, all this is of little help to you, since you want to convert
    a special document format *into* DDIF, not the reverse.
    
    (if there are any CDA expertes out there, then *please* correct any
    errors in the text below.)
    
    What you will *have* to do is write a CDA converter for your special
    format (let's call it NYMARATHON). The CDA architecture will see to
    that it's convertible into other formats. I'm not sure of the
    terminology, but I think that you will need:
    
    1) If you only want to convert outgoing then you'll need a front-end
    converter, DDIF$READ_NYMARATHON.EXE
    
    2) If you want to support incoming as well, then you'll need a back-end
    converter, DDIF$WRITE_NYMARATHON.EXE
    
    I find it likely that you will find outgoing support sufficient.
    
    Once you've got the CDA converter, you can convert your documents by
    simply calling DCL CONVERT/DOCUMENT (calling it from within a program
    is also possible, the name of the conversion routine is CDA$CONVERT) and
    convert into whatever format you want (DX?) 
    
    DDIF::CDA is a pretty active conference, and you'll get a lot of info
    about CDA Converters there.
    
    Another matter is how you implement the actual calls to the conversion
    routines. Writing a specific MR Gateway for it seems a bit unnecessary.
    I would suggest a customization of ALL-IN-1. ALL-IN-1 does have the
    tools necessary for catching an outgoing message and call conversion
    routines before the actual send happens.
    
    
    hope this helps,
    
    	Stefan

    Hi Helene,
    
    the german ALL-IN-1 includes a routine to convert .DOC_DTX file to .DX
    format and then you can convert the file to .DDIF. I do not know which
    features gone lose (bold, headline, tabs, ....).
    btw which version of ALL-IN-1 is in WIEN actual
    
    regards
    	Michael

Hello Stefan,

thank you for your reply.

The use of an own MR-gateway is necessary, because the conversion shall
not take place, if the message remains within the Mailbus-world of the
customer, and if there are recipients within this world and outside of it,
the ones inside should receive the customer owned format (let's call it
DECTEXT_ADV) and those outside of it should receive a format they can 
understand.

So the converter part is one thing, but the point where to convert is
another one. 

I am of the same opinion that converting inside ALL-IN-1 would be much easier,
but since the quantity of messages that does not leave their own world is
much bigger than the one that does, they want to convert at a later stage.

But I think, when I have a rough estimation on the development time of an
MR-Gateway (without development time of a converter) perhaps they are willing
to rethink their philosophy and look for a simpler solution.

Kind regards

Helene

    
    Helene,
    
    So you mean that the regular "in-house" message gets passed through the
    Mailbus in the usual manner, and all other messages pass through your
    specific gateway?
    
    Hmmm, maybe it isn't such a bad idea after all.
    
    cheers,
    
    	Stefan

    
    In reply to the original note, this is a rough estimate of the
    development time (excluding development of conversion routine)
    
    Assumtion: The functionality is roughly this:
    
    - fetch message from mailbox EXTERNAL.
    
    - check message type 
    
    - for User messages:
    
      o create new message for relay (assembly)
    
      o check bodypart type. If bodypart equals DECTEXT (I assume you're
        using this rather than one of the DECBODYs) then call conversion
        routine, otherwise just relay it.
    
       o for each adressee, remove last ROUTE element (ROUTE=EXTERNAL)
    
       o relay all other elements
    
       o post assembled message into MR
    
    - Service messages, Receipt Notifications etc
                                                               
      o create new message for relay (assembly)
    
       o for each adressee, remove last ROUTE element (ROUTE=EXTERNAL)
    
       o (not too sure about this) for each Intended recipient, Actual
         recipient, Reported Recipient etc, add last ROUTE element
         (ROUTE=EXTERNAL)
    
       o relay all other elements
    
       o post assembled message into MR
    
    
    Not a very complicated MR application, although I might have missed a
    few things. I think this is a case where one could get great help by
    the example Disassembly application,
    SYS$LIBRARY:MRIF$EXAMPLE_DISASSEMBLE.PAS.
    
    Let's see if I can break it down a bit:
    
    - Study MRIF carefully (2 man weeks)
    
    - Write Functional spec (2 man weeks)
    
    - Design structure of gateway (ie how to start/stop application, how
    fetch of msgs is triggered, logging etc) (2 man weeks)
    
    - Implement basic structure of gateway (3 man weeks)
    
    - Implement MRIF related stuff
    
    	o check and structure message types (1 man week)
    
    	o relay all "other" elements (3 man weeks)
    
    	o handle address ROUTE element (2 man weeks)
    
    - unforeseen (4 man weeks)
    
    - documentation and all other stuff that usually goes with.

    Hi Helene,
    
    for me it looks like you are reinventing the wheel. There is a MAILbus 
    ASSET available (MR/XLATE Gateway) converting documents from different 
    formats. May be that this gateway already does the job. Otherwise only
    an additional conversion routine has to be plugged in. Please look at
    WKRP::CYO_MB_PACKAGES (hit KP7).
    
    Rainer

    That's a lot I can work with, thank you very much!!!
    
    The conversion should not be a big issue then!
    I will check if the MR/XLATE Asset does the work, and if it does, I will 
    use the estimated times for the project to get a good price for the
    Asset. If it does not, I have a very good basis for the project. 
    
    BTW Michael, we in Wien use ALL-IN-1 Version 2.4 of course, but our big 
    customer COV has approx. 4-5000 users still on ALL-IN-1 Version 1.4(!!!),
    and approx. 1000 on 2.3.
    
    I'll be on customer site next week (to teach VMS SysMgmt,nothing to do
    with this project), so there will be no news on that.
                                                                    
    Kind regards
    
    Helene