With this in mind I would like to demonstrate how to easily integrate at least some minimal IM capability into SAP, being able to pass basic messages back and forth between IM accounts and R/3 accounts, and then to touch on the potential for IM beyond this.
A bit of background
Is an XML streaming protocols for instant messaging and presence developed within the Jabber community. Because the transmission of data is encapsulated in XML, and must conform to the controlling rules of XML, coupled with implementation rules for the protocol such as dialback for server to server communication etc., making XMPP a very secure messaging platform. Testimony to this is the absence of SPAM, in fact it could be robustly argued that if the backbone of SMTP was replaced with XMPP then SPAM would be history (but that is for another day).
Additionally, XMPP is a recognised Standard – the Internet Engineering Task Force (IETF) has formalized the core XML streaming protocols as an approved instant messaging and presence technology under the name of XMPP, and the XMPP specifications have been published as RFC 3920 and RFC 3921.
being the historical root of XMPP, has a number of server, client and component implementations surrounding it. In brief, a Jabber environment requires a:
- Server, which minimally consists of a core router or hub that directs XML streams between end points – usually those endpoints are components.
- Components: implement either server type features, or provide gateways or “transports” between the XMPP protocol and what ever else (in this case SMTP). Server type features may include offline storage for messages, Client to server connection handling, authentication, Server to Server communication etc.
- Clients – typically what the enduser experiences as a chat interface, but could equally be an automaton that is a message producer/consumer such as an SAP-XI node, MQ-Series etc.
For a more indepth ovreview, then this from the JSF is a good starting point.
Jabber and SAP
For my trial implementation, I didn’t want to change an R/3 system in anyway, so the logical solution is to start with what SAP has to offer by way of a messaging interface, namely the BCS (Business Communication Service). It is concievably quite easy to modify the BCS to include a new service class along side SMTP, SMS, Faxing etc., but inorder to keep this as “zero modification”, I have decided against that route.
The basic solution design is to use email on the R/3 side that is to be bi-directionally translated to Jabber based IM via a custom built XMPP transport component (SMTP Component pictured below).
Flow of messages between R/3 and Jabber Server.
Message Flow and Addresses
Because the messages are moving between two protocols, it is necessary to translate the from and to addresses between them, as the messages move through the SMTP transport Component. This is so that a message can find its correct XMPP destination (R/3 -> Jabber), and that the IM Message can be stamped with the appropriate From address so that when a reply is made, it will be able to find it’s way back again (Jabber -> R/3).
Configure SAPConnect for SMTP
SMTP inbound and outbound must be configured in R/3. There is a good discussion of this in the SAP help here . In the following section I have highlighted the main parts of the configuration that I used to get my SAP Netweaver NW4 evaluation system working – depending on your release your mileage may vary.
Set your profile parameters:
rdisp/start_icman = true
icm/server_port_2 = PROT=SMTP,PORT=25000,TIMEOUT=180
is/SMTP/virt_host_0 = *:25000;
SICF Virtual Host configuration
Configure your ICM via transaction SICF:
Ensure that your SAPConnect Virtual Host Data is configured for SMTP.
On the Service Data tab, ensure that the R/3 user for email receipt is configured (including client, language etc.).
In transaction SCOT, select the menu option for default domain – set this as the host receiving the email.
In transaction SCOT, you can optionally specify that recipt email is not expected. This makes it tidier in terms of the monitoring view of the send process.
Ensure that the SMTP node is configured – it usually uses the local OS transport mechanism such as sendmail (connecting to localhost port 25), and that the address range that will be sent to has a routing table rule in place. Make sure that the job that triggers the send process has been scheduled (SCOT => Settings => Send Jobs) – this is what shuffles the emails out on a periodic basis.
Finally – make sure that every R/3 account is configured correctly with an Internet Email Address. This is found in SU01, under address data, and communication methods.
The Jabber Component
Now that we have R/3 configured, we can move on to the Jabber side of things. I have created a transport component, that implements a simple gateway between XMPP, and SMTP. The component has been developed using Ruby and XMPP4R . By nature, a transport component has two main parts to it. It has the portion that implements the XMPP protocol, and the second part that implements the target protocol – in this case SMTP. There are other SMTP component implementation available such as smtp-t, but – inorder to simplify the sender and receiver addresses (See diagram above and below showing process flow and address translation) – I have decided to “roll my own”. XMPP4R is easy to use, and taps into Rubys simple threads implementation – something that is essential for developing components that have two event cycles – listiening for SMTP messages on ones side, and XMPP on the the other.
In my landscape I have a Netweaver R/3 instance with an SMTP interface named seahorse.local.net listening on 2500. My Jabber SMTP component has an SMTP interface of sapsmtp.local.net listening on port 25, and this is registered with the XMPP router called gecko.local.net. As both SAP, and the Component have to have both sending and receiving capabilities for SMTP, and this is all configurable, I’ve tried to ease this pain with a diagram:
Make sure all your designated hostnames are resolvable – this is a common mistake with Jabber.
To run the component you must have installed Ruby and installed the XMPP4R package. This also assumes that you have access to a Jabber server – I use jabberd2 , but there are a number available. You can find a good list here . ejabberd is good universal one, especially if you need to run win32.
Once you have access to your server, and have XMPP4R installed, download the component from here .
Unpack the .tgz file, and then cd into the smtpcomp/ directory. Here, you need to know the addresses, and port numbers of your landscape to convert them into command line options:
piers@gecko:~/code/ruby/smtpcomp$ ruby smtpcomponent.rb -h
-h this help
-s Jabber server router jid (gecko.local.net) – target Jabber server
-p Jabber server router port (5347) – target Jabber server port for components
-a Jabber server router auth phrase (secret)
-c Jabber component jid and smtpd name (sapsmtp.local.net) – name of THIS component
-r SAP system smtpd name (seahorse.local.net) – SMTP host of SAP
-q SAP system smtpd port (2500) – SMTP port of SAP
For my setup where I have a Jabber server, gecko.local.net, a component name of sapsmtp.local.net, and an SAP system seahorse.local.net with an SMTP service on port 2500, then the command line options operate like:
piers@gecko:~/code/ruby/smtpcomp$ sudo ruby smtpcomponent.rb -s gecko.local.net -c sapsmtp.local.net -r seahorse.local.net -q 2500
starting component at: sapsmtp.local.net
SMTPD going to listen on: sapsmtp.local.net/25
gecko.local.net http://jabber.org/protocol/disco#info to sapsmtp.local.net
Note: the use of sudo at the beginning of the command is to make the script run with root priveledges, as the SMTP interface of smtpcomponent.rb listens on port 25 which requires super user access. Also – you may need to specify the port for the component to connect to the router on (-p) and a password for authenticating with the route (-a).
The IM Message arrives…
Now for the return leg using reply to the original IM Message, which is translated back through the SMTP component and sent to R/3.
Message from firstname.lastname@example.org/Psi to email@example.com () subject: Re: Is it ready yet! : "no - stop pestering me"
Email in R/3
So what does this all mean?
What we have here is the ability to push events between R/3, and “A” another endpoint. By virtue of transport components, these events can traverse protocols, and can be integrated with just about any platform you care to think of because of client programming language support for XMPP (C, Java, Perl, Python, Ruby, Erlang to name some). To me, this all spells a universal messaging platform that is open, reliable, secure, standards compliant, that is ready to be used as a carrier for business data from alerts, to documents, to workflow events. It is worth taking a look at the Jabber Protocols page, which describes what processes, and functionality is currently supported, and what things are in the pipeline.
Currently Jabber clients routinely handle URLs, which make a good starting point for relaying Workflow items (integration points for BSPs, EP etc.). It also has specifications for RPC style encapsulation, and reference implementations for SOAP document transmission. Beyond this, Jabber messaging has the potential for embedding workflow objects ala Duet , to be interpreted by an extension to an existing Jabber client, and I haven’t even started on mobile technologies yet.
Please note that I have quoted extensively from documentation supplied by the JSF throughout, and wish to thank them for that and their continuing efforts in developing, and promoting Jabber and XMPP.