Introduction
This week we have taken a look at two different ways of sending E-mails from ABAP. But what people may not realize is that it is just about as easy to receive E-mails. The setup and sample that I am going to present here is based upon the WebAS 610 and higher technology. All of my samples were created on a 620 system.
Just like with sending E-mails, there is a little bit of configuration that must be done before we get started. You probably want to go ahead and make sure that your system is already configured for sending e-mails via SMTP before you even start any of this configuration. Once again we have the excellent resource of OSS note 455140. Not only does it have instructions for setting up outbound e-mail, but it also has a nice section on inbound.
The first thing we need to do is setup a user. This is the user that all the inbound processing requests will run under (This is section 2.A in OSS Note 455140). I named my user SAPMAIL. I gave the ID the required S_A.SCON profile in addition to any other profiles it will need to carry out the processing we are requesting in our e-mail.
Next we need to configure our SAPConnect Node in Transaction SICF. We will change the SAPConnect node to run under the user we just setup in the previous step. The following is a screen shot of our SAPConnect Node:
Step 5 of the OSS note states that you need to setup routing rules in your corporate mail server to redirect emails to your WebAS. This is true and necessary for receiving mails from the Internet. But for our test we can bypass this step. Our MS Exchange people are very busy and don't like to be bothered with requests for new rules. If you are inside your network you should be able to route an E-mail to your WebAS using its full Domain Name. For this example I am going to send a mail to my D15 system. It's full DNS name is kww-d15s.kimball.com. Therefore to route mails to this system without a rule in our Exchange system, I just need to address them as the following: test@kww-d15s.kimball.com.
Inbound Processing
We should be about ready to setup the configuration that tells the WebAS what program to execute upon Inbound Mail arrival. We can do this configuration from Transaction SCOT once again. In SCOT we choose Menu: Settings->Inbound Processing. This configuration table allows us to setup inbound processing rules based upon the recipient address and/or document content type. You then just supply the name of the class that you want to process this request. Your selection of classes will be limited to those that implement the interface, IF_INBOUND_EXIT_BCS and both if its methods, CREATE_INSTANCE and PROCESS_INBOUND. The following is a screen shot of our configuration table.
Example Application
I thought that it might be fun to give you an example implementation of this code that would actually be somewhat useful. Have you ever been in a meeting or at lunch when you get a call that something is wrong with a system that you support. Wouldn't it be nice if you had a quick, easy way to check your system status from a wireless PDA or cell phone. Well now you can! We are going to write an e-mail handler that will send you back the process overview (SM50) upon request.
We will start by creating a global class that I called ZCL_MAIL_INBOUND_SYS_CHECK. Like we said before it must implement interface IF_INBOUND_EXIT_BCS. That will give us two constant attributes (GC_CONTINUE and GC_TERMINATE), one static method (CREATE_INSTANCE) and one instance method (PROCESS_INBOUND). The way this exit class works is that the SAP Inbound mail handler will first call our static method to request an instance of our class(CREATE_INSTANCE). It then calls the instance method (PROCESS_INBOUND) with all the details about the incoming message (sender, content, attachments, etc.).
Attributes
The following is a screen shot of our global attributes. We only add one static attribute that keeps a pointer to our own instance. We will reuse this single instance during our CREATE_INSTANCE method. That way we only have one instance of the class at any time.
CREATE_INSTANCE
This is the first of our two interface methods. This is the static method that will return a pointer to an instance of class. If an instance doesn't already exist, it will create one. The following is our code:
PROCESS_INBOUND
This is the main instance method that will be called to process our inbound email. We start off with our local data declarations. Then we grab a pointer to the E-Mail Reply object that has already been created for us:
Next we are going to do a little check on the sender address. We only want to reply if the sender address contains our company's domain or the one for our cell phone provider. Hopefully this will cut down on the chances that our WebAS will get on someone's SPAM list.
Now we want to start building our reply. We are just going to submit SM50 and grab its list output. We will then convert the list to HTML and insert it into our reply object. Now most of the process to build the reply I put in a separate method (SEND_REPLY) for reuse. We will look at this code in just a minute.
We follow this up with some error handling.
Just incase anyone wants to cut and paste the code, here is the complete method all together.
SEND_REPLY
SEND_REPLY is our last method and the only one that didn't come from the interface definition. I broke this code out just to make it a little more reusable. We will take in a pointer to the reply object, the subject, and the message content.
We start off with a few local data declarations. Then I set a different sender into the reply message. I don't want the e-mail coming back from the user that this method is currently running under (SAPMAIL). I want it to appear to have come from our support mailbox. Therefore I change the sender to a different SAP User (KEGSAPSUP).
Next we build the message body, the message attributes, and then send it on its way.
In the end I send my email to D15Status@kww-d15s.kimball.com and I receive the following back a second or two later:
This week we have taken a look at two different ways of sending E-mails from ABAP. But what people may not realize is that it is just about as easy to receive E-mails. The setup and sample that I am going to present here is based upon the WebAS 610 and higher technology. All of my samples were created on a 620 system.
For another example of this technology you should have a look at the weblog gregor.wolf3/blog/2005/10/02/inbound-mail-processing-150-attach-files-to-opportunity by gregor.wolf3/blog.
ConfigurationJust like with sending E-mails, there is a little bit of configuration that must be done before we get started. You probably want to go ahead and make sure that your system is already configured for sending e-mails via SMTP before you even start any of this configuration. Once again we have the excellent resource of OSS note 455140. Not only does it have instructions for setting up outbound e-mail, but it also has a nice section on inbound.
The first thing we need to do is setup a user. This is the user that all the inbound processing requests will run under (This is section 2.A in OSS Note 455140). I named my user SAPMAIL. I gave the ID the required S_A.SCON profile in addition to any other profiles it will need to carry out the processing we are requesting in our e-mail.
Next we need to configure our SAPConnect Node in Transaction SICF. We will change the SAPConnect node to run under the user we just setup in the previous step. The following is a screen shot of our SAPConnect Node:
Step 5 of the OSS note states that you need to setup routing rules in your corporate mail server to redirect emails to your WebAS. This is true and necessary for receiving mails from the Internet. But for our test we can bypass this step. Our MS Exchange people are very busy and don't like to be bothered with requests for new rules. If you are inside your network you should be able to route an E-mail to your WebAS using its full Domain Name. For this example I am going to send a mail to my D15 system. It's full DNS name is kww-d15s.kimball.com. Therefore to route mails to this system without a rule in our Exchange system, I just need to address them as the following: test@kww-d15s.kimball.com.
Inbound Processing
We should be about ready to setup the configuration that tells the WebAS what program to execute upon Inbound Mail arrival. We can do this configuration from Transaction SCOT once again. In SCOT we choose Menu: Settings->Inbound Processing. This configuration table allows us to setup inbound processing rules based upon the recipient address and/or document content type. You then just supply the name of the class that you want to process this request. Your selection of classes will be limited to those that implement the interface, IF_INBOUND_EXIT_BCS and both if its methods, CREATE_INSTANCE and PROCESS_INBOUND. The following is a screen shot of our configuration table.
Example Application
I thought that it might be fun to give you an example implementation of this code that would actually be somewhat useful. Have you ever been in a meeting or at lunch when you get a call that something is wrong with a system that you support. Wouldn't it be nice if you had a quick, easy way to check your system status from a wireless PDA or cell phone. Well now you can! We are going to write an e-mail handler that will send you back the process overview (SM50) upon request.
We will start by creating a global class that I called ZCL_MAIL_INBOUND_SYS_CHECK. Like we said before it must implement interface IF_INBOUND_EXIT_BCS. That will give us two constant attributes (GC_CONTINUE and GC_TERMINATE), one static method (CREATE_INSTANCE) and one instance method (PROCESS_INBOUND). The way this exit class works is that the SAP Inbound mail handler will first call our static method to request an instance of our class(CREATE_INSTANCE). It then calls the instance method (PROCESS_INBOUND) with all the details about the incoming message (sender, content, attachments, etc.).
Attributes
The following is a screen shot of our global attributes. We only add one static attribute that keeps a pointer to our own instance. We will reuse this single instance during our CREATE_INSTANCE method. That way we only have one instance of the class at any time.
CREATE_INSTANCE
This is the first of our two interface methods. This is the static method that will return a pointer to an instance of class. If an instance doesn't already exist, it will create one. The following is our code:
PROCESS_INBOUND
This is the main instance method that will be called to process our inbound email. We start off with our local data declarations. Then we grab a pointer to the E-Mail Reply object that has already been created for us:
Next we are going to do a little check on the sender address. We only want to reply if the sender address contains our company's domain or the one for our cell phone provider. Hopefully this will cut down on the chances that our WebAS will get on someone's SPAM list.
Now we want to start building our reply. We are just going to submit SM50 and grab its list output. We will then convert the list to HTML and insert it into our reply object. Now most of the process to build the reply I put in a separate method (SEND_REPLY) for reuse. We will look at this code in just a minute.
We follow this up with some error handling.
Just incase anyone wants to cut and paste the code, here is the complete method all together.
SEND_REPLY
SEND_REPLY is our last method and the only one that didn't come from the interface definition. I broke this code out just to make it a little more reusable. We will take in a pointer to the reply object, the subject, and the message content.
We start off with a few local data declarations. Then I set a different sender into the reply message. I don't want the e-mail coming back from the user that this method is currently running under (SAPMAIL). I want it to appear to have come from our support mailbox. Therefore I change the sender to a different SAP User (KEGSAPSUP).Next we build the message body, the message attributes, and then send it on its way.
In the end I send my email to D15Status@kww-d15s.kimball.com and I receive the following back a second or two later:
147 Comments
