A: Yes, there are actually a couple of different ways of going about this. The first way is to call the class using either the JAVA or Run Java (RUNJVA) command. The second is by calling the Java classes/methods from the JavaMail API directly from RPG.
Using JAVA or RUNJVA
One of the first things you would probably want to do if calling one of the examples in Michael's article would be to change the hard-coding of the addresses, subject, and body of the message to be parameter driven.
For example, change this:
public static void main(String[] argv)
{
String to = "
String from = "
String subject = "Test Message";
String myMessage = "Hello";
to something like this:
public static void main(String[] argv)
{
String to = argv[0];
String from = argv[1];
String subject = argv[2];
String myMessage = argv[3];
In this code example, we're assigning the incoming parameters (the argv array) to our String variables. Obviously, we would have to ensure that we called this class with a parameter list that matched this order.
This is what a CL program call to this class might look like using RUNJVA:.:
DCL VAR(&to) TYPE(*CHAR) LEN(256)
DCL VAR(&from) TYPE(*CHAR) LEN(256)
DCL VAR(&subject) TYPE(*CHAR) LEN(256)
DCL VAR(&myMessage) TYPE(*CHAR) LEN(256)
RUNJVA CLASS(SimpleExample) PARM(&to &from &subject &myMessage) + CLASSPATH('/java')
ENDPGM
When using this method to run a Java class, there are a couple of things to note:
- The RUNJVA and Java classes have a 256-character limit on any single parameter that you wish to pass. This typically is not a problem with an Internet email address or subject, but it is most definitely one when dealing with the body of the email.
- When the command is executed, another job will be submitted to the subsystem it is running in--that is, the Java Virtual Machine (JVM). This can be a problem if the command is running in a subsystem that only allows one job to run at a time. The command will fail.
- The command will also produce a spool file that details the status of the Java class you just called. If it runs normal, you will find it just tells you "Java program completed."
You can find these commands documented in the iSeries Information Center by searching on RUNJVA.
Calling Java Classes/Methods Directly from RPG
When using this method, you would make calls to the JavaMail API directly from RPG instead of having a Java class do it for you and then having to call that class from RPG or CL.
For example, let's look at a piece of code from one of Michael's examples in his article:
Properties props = new Properties(); props.put("mail.smtp.host", host);
In the last two lines of code, we are creating a Properties object and putting the name value pair of our SMTP server in our Properties object for later use by the Session class.
To do this same thing from within RPG, we would code it something like this:
D smtpSvr S O CLASS(*JAVA:'java.lang.String')
D propFile S O CLASS(*JAVA:'java.util.Properties')
/free
smtpSvr = crtString('mail.yourwork.com');
keyName = crtString('mail.smtp.host');
propFile = crtPropFile();
addProp(propFile:keyName:smtpSvr);
/end-free
As you can see, we have defined three new String objects (the Object data type is new as of V5R1 and is what allows us to deal directly with Java). We will be using these to put our character values in, since the methods to create the Properties file and add the name value pair accept String objects.
The next couple of lines create the String objects for the SMTP server and the key value for the name value pair that you will be putting in the Properties file.
The last couple of lines create the Properties object, assign it to the propFile object variable, and then add the name value pairs to the propFile object.
As you can see, calling a Java class or method is very similar to calling a prototyped procedure in RPG. These methods are actually ones from the java.lang and java.util packages that have been prototyped for our use, as follows:
D 'java.lang.String':
D *CONSTRUCTOR)
D CLASS(*JAVA:'java.lang.String')
D 32000A CONST VARYING
D crtPropFile PR O EXTPROC(*JAVA:
D 'java.util.Properties':
D *CONSTRUCTOR)
D CLASS(*JAVA:'java.util.Properties')
D STATIC
D addProp PR O EXTPROC(*JAVA:
D 'java.util.Properties':
D 'setProperty')
D CLASS(*JAVA:'java.lang.Object')
D O CLASS(*JAVA:'java.lang.String')
D O CLASS(*JAVA:'java.lang.String')
Similar to procedure prototypes, these prototypes define the interface to the Java methods (procedures) we wish to call from our RPG program. (We define a name for our method/procedure, a return value, and its parameters.)
Let me explain what's in the first prototype:
- The crtString is the name you will use in the RPG program.
- The PR defines this code as a prototype.
- The O tells us that the return type of this method call is an object.
- The code after the EXTPROC tells us that we are dealing with a method written in Java (*JAVA), that the qualified class name that the method resides in is ('java.lang.String'), and that the actual call will be to the constructor of that class (*CONSTRUCTOR).
- By qualifying the name of the class, the CLASS keyword further defines the return and parameter values by specifying what objects we will be returning/sending.
- The last line defines a character field that will not be changed by our method call.
I have just brushed the surface on calling Java directly from RPG, but you can find more information concerning this subject in the WebSphere Development Studio: V5R1 ILE RPG Programmer's Guide in chapter 11,"RPG and the eBusiness World."
In summary, it's easy enough to get around the issues discussed in calling the Java class with either the RUNJVA or JAVA command (with a little extra coding). But I have found that calling the Java classes/methods directly from RPG gives you more control and tends to be more flexible as you decide to use more that the JavaMail API has to offer.
--Brandon Wahl
LATEST COMMENTS
MC Press Online