DataXstream OMS+

Server Programming in JCo Part 2

Server Programming in JCo Part 2

This is a continuation of Server Programming in JCo Part 1. In this post, I will deal with the setting up the constructs of the java program acting as the server.

The key Java object in JCO server programing is the JCO.Server, which is easy to use, but very powerful. At a high level, only these three things are needed to setup the server class:

  1. extend the JCO.Server class
  2. in your constructor, call one of the JCO.Server constructors
  3. override the handleRequest(JCO.Function function) method

Below is an example of a basic server setup. When the Server is running, all requests coming from the configured SAP system, will be sent to the handleRequest() function

public class JcoServer extends JCO.Server
{
public JcoServer(String gwhost, String gwserver, String programid, IRepository repository)
{
super(gwhost,gwserver,programid,repository);
}
protected void handleRequest(JCO.Function function)
{
//code for the function goes here. explained later
}
}

To actually start the server, standard procedure is to write a wrapper class that will manage the starting and stopping the server, getting connection parameters, setting up the repository, etc.

The JCO.Repository Class
The JCO.Repository class is an important object. This object stores the template for the function module you created, or in our case, borrowed, from inside of SAP. There are two different ways to create the JCO.Repository:

  1. Create it Manually in java code with JCO.MetaData objects
  2. Have the JCO.createRepository() function call SAP and return the function template for the import, export, and table structures automatically

In the code below, we are leveraging the SAP created repository . The repository keeps track of the function metadata, so as your server runs, it keeps the metadata of the calls in the repository. keep in mind that you are making an RFC call into SAP to get the information, so you will need the following authorization objects and function groups:

  • authorization objects S_RFC, ACTVT:16, FUGR
  • Function Groups RFC1, SDIFRUNTIME, SG00, SRFC, SUNI, SYST

The JCO.Client Class
The JCO.Client class is need here because we are creating the repository from SAP automatically. If we were to build the metadata manually, we wouldn’t need it. We could also create connection pooling for this, but Its only for the metadata lookup, so I’m not doing it. I’m also using a properties file to create the client connection to SAP. This is quite useful and has several built in connection parameters. I’m just using the bare minimum here:

  • jco.client.client SAP client
  • jco.client.user Logon user
  • jco.client.passwd Logon password
  • jco.client.lang Logon language
  • jco.client.sysnr SAP system number
  • jco.client.ashost SAP application server
  • jco.client.gwhost Gateway host
  • jco.client.gwserv Gateway service

public class JcoWrapper
{
private JcoServer jcs = null;

public static void startServer()
{
java.util.Properties props = new java.util.Properties();
java.net.URL url = ClassLoader.getSystemResource(“sapconnection.properties”);
props.load(url.openStream());

JCO.Client client = JCO.createClient(props);

IRepository repository = JCO.createRepository(“REP”, client);

JcoServer jcs = new JcoServer
(“gwhost”, //gateway host, often the same as host
“sapgw00”, //gateway service, generally sapgw+
“JCOSERVER01”, // corresponds to program ID defined in SM59
repository);

jcs.start();
}

public static void stopServer()
{
jcs.stop();
}

public static void main(String[] args)
{
this.startServer() ;
}

}

So now we with parts 1 and 2 we have the ability to listen for SAP calls. Part 3 will deal with actually doing something with data we receive.

Twitter Poster sponsor : Top baby names

Leave a reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.