NA
| Term | Definition |
|---|---|
| Inbox |
This is the standard mail server folder where each new incoming email arrives. |
| Oracle Processed |
After a message is downloaded, it is moved to this folder where it stays forever. |
| Oracle Retry |
If for some reason a message cannot be downloaded, then it is moved to the Oracle Retry folder. |
Here is the sequence of events for an email message:
Email comes to Inbox.
The DP preprocessing thread puts the message uid IEM_RT_PP_QUEUES with flag=’N’.
DP postprocessing gets a batch of messages with flag=’N’ for processing and stamps it as ‘A’.
After a message is downloaded, mark it as “M” and then try to move it to the Oracle Processed folder.
If a move message failure occurs, then mark it as “O”.
If a message cannot be downloaded after 5 tries, then mark it as “F” and move it to the Oracle Retry folder (if the message exists in Inbox).
If a message does not exist in Inbox because, for example, some other process deleted it or it was manually deleted, and the download processor tries to download it, then after 5 unsuccessful tries mark the message status as "Q".
Refer to the definitions at the head of this section.
3. What are the different flag values in the iem_rt_pp_queue table?The following table shows the flag values.
| Flag | Cause | Admin Action | Comments |
|---|---|---|---|
| N | When pre processing thread create an entry for a message in Inbox | None | This is a normal temp.condition. |
| A | Post processing thread starts working on an entry. | None | This is a normal temp.condition. |
| M | Message downloaded successfully. Next step is to move the message. | None | This is a normal temp. condition. |
| O | Error encountered while moving the message to Oracle Processed folder. | Need to manually move the message from Inbox to Oracle processed. | Message will remain in this status permanently. |
| F | Message cannot be downloaded due to error and moved to Oracle Retry folder. | Admin needs to check the error log from DP console and take appropriate action. | Message will remain in this status permanently. |
| Q | Messages cannot be downloaded as they no longer exist in Inbox. | Admin needs to check error from DP console as well Check if these messages are already processed or not. | Message will remain in this status permanently. |
The actions are as follows:
Monitor the DP admin console and DP logs from there.
Check if messages are stuck in Inbox for a long period of time.
Check what kind of messages are in the Retry folder.
Check if there are records with flag “O” in the IEM_RT_PP_QUEUES table. In that case they need to move these message manually to the Oracle Processed folder.
Email Center tries to have minimum interaction with Email Server. So as part of design, after a message is moved to the Oracle Processed folder, it stays there.
What should we should do with Oracle Retry folder messages?Find the corresponding error message from the download processor admin console or query the IEM_DP_LOGS table. Doing a comparison based on rfc822_message_id and subjects and so on can do this.
From the error message, try to see if it is related to the environment such as folder connection/mail server down/A20 append issue, and so on. These are mail server related error messages, and for these you can try to move these message again back to Inbox.
If there are message malformed issues like message boundary asd so on is missing, in these cases the message cannot be downloaded.
System is trying to process a very very large message, and as a result there may be some contention in getting resources.
The IEM_RT_PP_QUEUES table contains a large number of records with status “O”. Unless these messages are moved from Inbox, the pre processing thread won’t be able to get new entries into this table.
The mail server is resetting message uid's, and this can cause an issue if IEM_RT_PP_QUEUES contains a large number of records with flag "O', "F", "Q". In that case, new messages with the same message uid won’t be able to create an entry in this table.
There is as such no limitation, but if business does not require processing of large sized emails, it is better to avoid them to provide a better response from the system. Large sized email can cause a contention issue with a mail server because considerable time may be required to download messages.
We noticed that sometimes download processor threads are down. What could be the possible cause and action to resolve this issue?To know the reason, enable logging and provide the information to development for further research. This could also be due to heap memory exhaustion. Is sufficient memory available? Iit could be advisable to check it by increasing the heap size in the OC4J instance. Also check from the OAM console and look into the ICM logs that are associated with the DP process.
How many times does the download processor try to process a message? Can it be configured?Download Processor tries to download a message 5 times, and it cannot be configured.
Does the download processor encounter contentions? How to avoid that?Please make sure that all threads are not looking into a single account. Splitting the processing across multiple accounts is the way to go. This is a must if the volume of email is more than 200 per hour.
Also try to avoid processing large sized emails, or move these large sized emails to a separate account.
When the preprocessing thread looks to write into new email information, the only unique way to identify a new email is by the message uid that is return by the mail server. There are some mail servers where this message uid can get reset. So if records are there in the iem_rt_pp_Queue table, in that case, a new message cannot be processed if they have the same message uid (due to mail server resetting the value). This is so because while inserting a record into the iem_rt_pp_queues table, DP checks whether the same message uid for that account exists or not to maintain uniqueness and not duplicate processing of emails.
Can the download processor automate clearing records from the iem_rt_pp_queue table?In some cases it can be done automatically. Development is working on this.
What are the logging mechanisms available in download processor. and what is the recommendation for capturing that information?Goto System Administrator -> System Profile Set the log at user level, so need to check user level check box. Select Username put FND%DEBUG% in search criteria In the profile screen, set the following value FND: Debug Log Enabled - Y FND: Debug Log Level - Statement FND: Debug Log Module - IEM% Apart from above 3, set the following profile value as well at site level. Concurrent:GSM Enabled - Y Save the record. Now login as that user, send out email. Once you encounter the issue, complete the process (let it take 10 mins or whatever). comeout of application. Stop logging. Then do the following: select to_char(timestamp,'ddmmyy hh24:mi:ss'),module,message_text from fnd_log_messages where module like 'IEM%' Order by timestampHow we can reprocess Oracle Retry folder messages?
In some cases moving a message manually to Inbox from the Retry folder can reprocess the message.
If a message can be reprocessed from the Oracle Retry folder, why move it there?Sometime intermittent environment-related issues cause the download processor to encounter an error. As a result, messages cannot be downloaded in 5 attempts and are moved to the Retry folder. After this intermittent issue is resolved, the same messages can be processed again.
Can download processor be started and stopped through a script?No, and we don’t recommend trying to achieve through customizing.
We are seeing lot of error messages in the download processor log. Should we be alarmed if there are any log messages that shows error?What we recommend is that you review the errors and see whether they caused messages to be moved to the Retry folder or not. You can compare the data by checking message subject,rfc822_message_id, sender, and so on. Some of the common error you can find are as follows:
javax.mail.MessagingException: Missing start boundary
The most likely cause for this error is malformed messages. This means that the standard JMA API is not able to parse the message. If the message is in the Retry folder, then the admin can try to manually move it to Inbox to see if in a second try these can be processed or not. If not, try to see if these message can be opened by Outlook Express or not. If not, then Email Center cannot process them. If these message can be opened by Outloek Express, then development would like to see them. The DP parsing program may need to improvement to process these types of emails.
java.sql.SQLException: Inserted value too large for column
This can be a bug. Please log a tar. Development would like to have a look at these.
com.sun.mail.iap. CommandFailedException: A66 NO :
These are some of the common errors that can get logged in DP logs and are email server issues. Please verify whether these messages are getting processed by Download Processor on the 2nd retry.
Download Processor can download all standard RFC822 formed email. It uses the JMA API to download email. So the limitation is with the JMA API. We have seen that there are issues with malformed emails, but these should be <.0001% of the emails.
Does Download processor interact with Mail Server and its file system?Download Processor does not write to Mail Server. It calls stanadrd JMA API calls, and sometime it is possible that these JMA APIs are writing to email serverp This is independent of Oracle Email Center code.
We have seen the download processor not downloading emails from the inbox, and the number of records in the inbox folder keeps increasing. Sometimes we have seen this is due to some error at the Cisco email center, and sometimes we just need to bounce the download processor and this resolves the issue. We have also seen once we start the download processor. a few records get added to the retry folder. Would like to know why we need to start the download manager, why was it not able to handle exception the first time around, why does it handle the exception on restart?If there is a mail server related issue, it can cause a generic problem at the download processor. So it cannot download emails. and as a result the email count in Inbox can increase. In such type of scenario, please check the mail server and find if there are any issues. Also, in order to understand what exactly is happening, enable logging. Due to this type of generic issues, all threads may be errored out or stuck in contention. Restarting the download processor clears these and enables it to spawn a new set of threads.
Is there a way that we can monitor the download processor and get a status report in a email or a pager alert if the download manger is down etc?Try to use the Download Processor Notification program so that it can send the DP console to a user with Email Center Administrator responsibility.
We noticed that mail files mbox - imap process files are large. Oracle processed inbox is 500 MB, and the higher it gets, the better is the chance of corrupting - is there a faster way to empty that?Download Processor cannot delete the emails from the Oracle Processed folder. This is something that the mail server needs to handle with a rule.
How to stop only one manager?There is always one Download Processor, and it spawn number of threads.
What is the purpose of Email Center Diagnostics, and when should they be used?Email Center Diagnostics provide some test cases to check the health of the system. Whenever the download processor encounters an error, we suggest to run these tests to see if there are some connectivity issues or mail server related issues. So please run these whenever you encounter any mail downloading problem.
We can see Oracle Processed folder count is increasing, but email is not visible in the Email Center agent console.That implies download processor is working fine. So there are three possible tables where email is visible IEM_RT_PREPROC_MAILS -> You can identify the email based on subject by issuing the query select a.subject,b.message_id from iem_ms_base_headers a,iem_rt_preproc_emails b where a.message_id=b.message_id.
If email is present here and the Email Center processing concurrent program is running, then that implies there are some issues in processing these emails that can be diagnosed further by enabling fnd logging to further troubleshoot.
IEM_RT_PROC_EMAILS -> You can identify the email based on subject by issuing the query Select message_id,subject from iem_rt_proc_emails. If email is visible here, that means that both download processor and the Email Center processing concurrent program are working fine. It could be an access issue that a particular agent may not have access to see this email. Try to see if emails are visible from the supervisor queue or not.
IEM_ARCH_MSGDTLS –-> You can identify the email based on subject by issuing the query Select message_id,subject from iem_arch_msgdtls
If you can view emails in this table, that means both download processor and Email Center processing concurrent program are working fine. There may be some auto processing rules setup that is either deleting or resolving emails by some custom procedure or auto-create or update SR action. As a result. emails are resolved instead of appearing in the Email Center console. So you need to revisit the rules.