E-Mail Triage App - Feedback Learning Process NodeJs Dev Challenge

Currently, customer team is spending more time in resolving the work items, which were created from each email received from the consumers (end customer).  To serve consumer quickly and better, the customer team want to optimize the work items creation by eliminating the categorizing the emails.

Please note this is  part of the series of challenges for a large enterprise solution and also lot of challenges are upcoming followed by this E-Mail Triage App challenge.
Hence, customer want to introduce a new system with the coloration of machine learning (ML) and existing software systems. 

With the introduction of “E-Mail Triage App”, the volume of unsecure email handling would needs be reduced in the overall ecosystem of software systems. TIBCO invokes an API exposed by “E-Mail Triage App” to send the mail content.  The “E-Mail Triage App”, applies the identification logic and replies with the mail category. TIBCO creates the work item with appropriate status in the SFDC.  In addition, there is a twostep feedback loop a) feedback capture process and b) Learning process. 

First this is how the Identification process works.

For detail please refer the previous challenge https://www.topcoder.com/direct/contest/detail.action?projectId=30069524

Once identification Process is complete inside SFDC the email category is verified using human intervention, please refer the following image.



And finally as per the following image the feedback process of email Triage application works:


Please note, one addition to above image that after receiving data from above mentioned SFDC system, the system will invoke SIMON to receive email body content, the details parameter for both system mentioned below.

Initially Email Triage App will invoke SFDC using OAuth 2.0:


Once authenticated, Salesforce will return access code in the response as JSON (See below example. Please note below is a screen capture from a different app. Your values will be completely different.)

ALL Subsequent requests to access records/query records should pass the access token in the Athorization header of HTTP Post. 



Example Request – Opportunity Workitem

/services/data/v43.0/query/?q=SELECT+ Email_To__c+ Email_Subject__c + Date_Email_Rcvd__c + Cognitive_Decision_Acceptance__c + Cognitive_Rejection_Reason__c + Cognitive_Rejection_Comments__c +from+OpportunityWorkItem__c+where+Cognitive_Decision_Acceptance__c+!=+null -H "Authorization: Bearer token"

 
The feedback learning process should be implemented as a cron job. In the cron job, it does something as below:

Loop
     Call SFDC API to get the feedback.
     Exit the loop if received non-successful response from SFDC API (or error), or reached 3 times
     (the threshold should be configurable).
EndLoop 


Loop
     Call SIMON API to get the email content with the workitem ID received from above.
     E xit the loop if received non-successful response from SIMON API (or error), or reached 3 times
     (the threshold should be configurable).
EndLoop 

And here is an example JSON with return from SFDC

{
  "totalSize": 1,
  "done": true,
  "records": [
    {
      "attributes": {
        "type": "OpportunityWorkItem__c",
        "url": "http://www.abc.com"
      },
      "Id": "a0v2a00000bwbpEAAA",
      "Mail_Class__c": "SPAM",
      "Email_To__c": "xyz@abc.com",
      "Email_Subject__c": "Fwd: Inertial Sense - Dental/Vision Quotes",
      "Date_Email_Rcvd__c": "2018-06-01T11:24:27AM",
      "Cognitive_Decision_Acceptance__c": "Incorrect",
      "Cognitive_Rejection_Reason__c": "This should have been a SPAM not and RFP",
      "Cognitive_Rejection_Comments__c": ""
    }
  ]
}

Now we have to request to SIMON with the “Id” from above request with following data.

{
  "version"        : "1.0",
  "source_system" : "FEEDBACK",//DEDUP will be another option
  "target_system" : "GLIC ECM",
  "req_trigger_by" : "ABC1234",
  "req_trigger_dt" : "2018-08-17,20:45:23",
  "get_rfq_documents" : [
    {
     //either rfq_email_workitem_id or rfq_opportunity_id will be in the request
      "rfq_email_workitem_id" : "RFQEMAILWORKITEMID",
      "rfq_opportunity_id" : "RFQOPPORTUNITYID",
      "doc_types" : "EMAIL"// can accept EMAIL, ALL
      }
  ]
}

 Now SIMON will return the following

{
  "version": "1.0",
  "source_system": "GLIC ECM",
  "target_system": "FEEDBACK",
  "res_trigger_by": "ABC1234",
  "res_trigger_dt": "2018-08-17,20:45:23",
  "rfq_documents": [
    {
      "rfq_email_workitem_id": "RFQEMAILWORKITEMID",
      "rfq_opportunity_id": "RFQOPPORTUNITYID",
      "rfq_document": [
        {
          "document_type": "EMAIL",
          "content_type": "application/pdf", 
          "content_binary": "binary content of the document",
          "content_text": "text content of the document"
        }
      ]
    }
  ]
}

Please use only “content_text” for receiving email body content. 
After Email Triage App received the response, it should first parse the email-body, and the parsed email-body will be sent to the Watson. For parsing requirement please refer the previous challenge https://www.topcoder.com/direct/contest/detail.action?projectId=30069524 .
 
And the request data to send to Watson API is like below (Please check Watson ML REST specification here: https://watson-ml-api.mybluemix.net ):

And here is the JSON input parameter
// For feedback applying back to Watson service
{
  "email_body": [['email body sample']],
  "values":[["SPAM"]]
}

 Watson Documentation: https://www.ibm.com/watson/developercloud/conversation/api/v1/node.html
 
The label corresponds to the category (e.g. SPAM in values field of SFDC response), and the mail corresponds to the parsed email_body.

Audit
We need to store information and details for every API request when E-Mail Triage App is invoking Watson, SFDC and SIMON for auditing and logging purpose.  Note that the audit data should be stored into IBM Compose for MongoDB.

Configuration
The Watson API, SFDC API, and SIMON API endpoints and their credentails should all be configurables. 
 
Technology overview 
It should be deployable in the IBM Cloud as a PaaS component.

• JavaScript
• JSON
• REST
• Backend
  • Node.js 8
  • Express 4.16
  • Passport 0.4
  • node-cron 1.2.1

 

Final Submission Guidelines

Submission Deliverable
- Source Code
- Detailed deployment guide and verification guide
- Working IBM Cloud deployment for verification