[ 
https://issues.apache.org/jira/browse/JAMES-2658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16762498#comment-16762498
 ] 

Raphaël Ouazana commented on JAMES-2658:
----------------------------------------

Hi Michael,

 

If I get your point correctly, you'd like a service that is:
 * async
 * json based

As seen, that does not go very well with a classic mail pipeline. But what 
about a service that is called client side then? The client will have all it 
needs (already jsonified mails, easily async support) to go your way, no?

The only caveats I see is the handle of the retry process client side (I mean 
if the user quit during this processing).

Regards,

Raphaël.

> Generic mailet to call an external microservice, and add extra information to 
> an email
> --------------------------------------------------------------------------------------
>
>                 Key: JAMES-2658
>                 URL: https://issues.apache.org/jira/browse/JAMES-2658
>             Project: James Server
>          Issue Type: Wish
>            Reporter: Michael Bailly
>            Priority: Minor
>
> Hello team. This is a Request For Comments for a feature, to be able to add 
> extra information to an email on delivery to a local mailbox.
> h2. Principle
> the mailet calls a remote webservice, with a pre-specified payload. It gets 
> back, either an error, or another specific payload. This payload can instruct 
> the James server to add informations to the email. The first case, that we 
> handle here, is to add extra headers.
>  
> h2. Implementation
> OK, I'll try to map the mailet syntax, but I'll make mistakes, it's to 
> illustrate the principle.
> James configuration:
> {{<mailet match="..." class="AddExtraInfos" 
> endpoint="https://server.com/api/infos"; />}}
> Seeing this, the mailer issues a POST on {{[https://server.com/api/infos]}} 
> with the following payload structure:
> {
>  {{  "messageId" : "messageId",}}
>  {{  "from" : {}}
>  {{    "address" : "f...@test.com",}}
>  {{    "personal" : "first_name last_name"}}
>  {{   },}}
>  {{  "to" : [ {}}
>  {{    "address" : "t...@test.com",}}
>  {{    "personal" : "first_name last_name of to1"}}
>  {{   } ],}}
>  {{  "cc" : [ {}}
>  {{    "address" : "c...@test.com",}}
>  {{    "personal" : null}}
>  {{    }, {}}
>  {{    "address" : "c...@test.com",}}
>  {{    "personal" : "first_name last_name of cc2"}}
>  {{    }, {}}
>  {{    "address" : "c...@test.com",}}
>  {{    "personal" : "first_name last_name of cc3"}}
>  {{   } ],}}
>  {{  "bcc" : [ ],}}
>  {{  "Received" : "Mon, 28 Jan 2019 07:56:43 +0000",}}
>  {{  "Date" : "Mon, 28 Jan 2019 07:56:43 +0000",}}
>  {{  "in-Reply-To" : "messageId_in_reply_to",}}
>  {{  "subject" : "IMPORTANT: Testing The Priority Inbox",}}
>  {{  "body" : "\nDear, \n\n this a test of the priority inbox\n 
> regards,\nfirst_name last_name\nDirector Tester",}}
>  {{  "attachments" : [{}}
>  {{    "file_size" : "243534",}}
>  {{    "content_name" : "presentation.pdf",}}
>  {{    "content_type" : "APPLICATION/PDF"}}
>  {{    }, {}}
>  {{    "file_size": "243534",}}
>  {{    "content_type" : "APPLICATION/PDF",}}
>  {{    "content_name" : "performance.pdf"}}
>  {{    }],}}
>  {{  "emailFolder" : "INBOX",}}
>  {{  "user" : "first_name last_name of to1",}}
>  {{  "alternativeAddress" : [ "t...@test.com", 
> "first_name.last_n...@test.com" ],}}
>  {{  "X-Spam-Flag" : "NO"}}
>  {{}}}
> Worth noting: all those attributes are JSON formatting of an email contents, 
> EXCEPT:
>  * emailFolder : the destination folder of the email
>  * user & alternativeAddress : the user the email is delivered to
> This mailet expects a specific format for the response. Here is a proposal:
> 1/ "bypass" (do nothing)
> {{{}}}
> 2/ "add headers"
> {
>    "addHeaders": [
> {name: "X-INFO1", value: "some header value"},
>  \{name: "X-INFO1-SCORE", value: "0.4"}
>    ]
>  }
> h3. Handling failure
> The mailet may support a specific attribute to define the behaviour in case 
> of failure.
> {{<mailet match="..." class="AddExtraInfos" 
> endpoint="https://server.com/api/infos"; on-failure="ignore" />}}
> h3. Configuring retries
> The mailet may support a retry parameter, allowing to retry x times before 
> "really" failing. The additional, optional retry delay parameter could set 
> the time, in seconds, to wait between each retry.
> {{<mailet match="..." class="AddExtraInfos" 
> endpoint="https://server.com/api/infos"; on-failure="ignore" retry="5" 
> retry-delay="0.5" />}}
> h3. Setting blocking behaviour
> Some processing may not require an immediate response, and may allow further 
> processing of the mailet chain. Here, either the "blocking" or the "async" 
> attribute, I can't choose, may be used.
> {{<mailet match="..." class="AddExtraInfos" 
> endpoint="https://server.com/api/infos"; on-failure="ignore" retry="5" 
> retry-delay="0.5" blocking="false" />}}
> or, as a second proposal
> {{<mailet match="..." class="AddExtraInfos" 
> endpoint="https://server.com/api/infos"; on-failure="ignore" retry="5" 
> retry-delay="0.5" async="true" />}}
> h2. Things I don't know
>  * Where to send email on failure, if the "on-failure" attribute is not 
> "ignore".



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Reply via email to