The new SAP NetWeaver RFCSDK is now available for official download - this opens the way for supported next generation Open Source Connectors such as sapnwrfc for Perl, and sapnwrfc for Ruby.

Where to get it?

You need to go to the SAP service Portal for Software downloads, and follow the path of: Download -> Support Packages and Patches -> Entry by Application Group -> Additional Components -> SAP NW RFC SDK -> SAP NW RFC SDK 7.10 -> SAP NW RFC SDK 7.10 .

There is an accompanying OSS note: 1025361.

Impact on Connectors

Clearly - this is SAPs way forward in the RFC area of closely bound system integration, so all existing connectors (and 3rd party products) will eventually have to migrate to it.

This is also true of code that is based on the existing connectors for Perl and Ruby. For Perl - there will be a migration from SAP::Rfc -> sapnwrfc, and likewise for Ruby moving from saprfc -> sapnwrfc (The client side implementation for the new sapnwrfc connector for Python is nearly finished, with the same implications).

My thanks and congratulations go out to the SAP NW RFC Team (NW AS ABAP Connectivity) - through their efforts, and willingness to engage the community, they have made it possible for us frustrated hackers to have a little more fun :-)

This means that eventually - all the RFC connectors, and 3rd party products will need to be updated to use the new under-carriage.

So whats the big deal?

New Features

• unicode in the core, with utf-8 to utf-16 conversion tools
• intelligent ABAP <=> X helper functions to ease type translations
• deep structures
• interface discovery
• interface, and structure caching

This has lead to a complete overhaul of the Ruby, and Perl Connectors, with the aim to take advantage of the new NW SDK features, and to produce connectors that create a more intuitive bond between the underlying RFC API, and the natural features of each Dynamic Language.

Call for testers

Obtaining the Connectors, and Netweaver RFC SDK

For Ruby - download from the RAA. Follow the instructions in the included README file. Documentation is available Here. A GEM install package for Win32 has been built available here.

For Perl - download from CPAN. Again - follow the instructions in the included README file. Documentation is available Here. A PPM install package for Win32 has been built available here.

If you are interested in trialling/testing the new connectors, then along with the installing the new connectors (above) you will need to obtain the new Netweaver RFC SDK. in order to do this, please register your interest with me, ensuring that I know how to contact you, and what your platform requirements are, and with the help of the NW RFC team at SAP I will get the relevant details to you.

Ruby Examples

 # specify a YAML base config file or pass connection
 #   parameters directly to rfc_connect()
 SAPNW::Base.config_location = './config_file.yml'
 SAPNW::Base.load_config
 conn = SAPNW::Base.rfc_connect

 # get the system and connection details
 attrib = conn.connection_attributes
 $stderr.print "Connection Attributes: #{attrib.inspect}\n"

 # lookup the dictionary definition of an Function Module
 fds = conn.discover("STFC_DEEP_STRUCTURE")
 $stderr.print "Parameters: #{fds.parameters.keys.inspect}\n"

 # create an instance of a Function call
 fs = fds.new_function_call

 # populate the parameters - structures and table rows now take hashes of field name/value pairs
 fs.IMPORTSTRUCT = { 'I' => 123,
                     'C' => 'AbCdEf',
                     'STR' =>  'The quick brown fox ...',
                     'XSTR' => ["deadbeef"].pack("H*") }

 # execute the RFC call
 fs.invoke
 $stderr.print "RESPTEXT: #{fs.RESPTEXT.inspect}\n"
 $stderr.print "ECHOSTRUCT: #{fs.ECHOSTRUCT.inspect}\n"

Config file (refer to the sap.yml file in the download):

ashost: ubuntu.local.net
sysnr: "01"
client: "001"
user: developer
passwd: developer
lang: EN
trace: 2

Test it out - and give your feedback.

Perl Examples

 use sapnwrfc;
 use Data::Dumper;

 # specify a YAML base config file or pass connection
 #   parameters directly to rfc_connect()
 SAPNW::Rfc->load_config;
 my $conn = SAPNW::Rfc->rfc_connect;

 # lookup the Function Module
 my $fds = $conn->function_lookup("STFC_DEEP_STRUCTURE");

 # initialise a call instance
 my $fs = $fds->create_function_call;

 # set the parameters
 $fs->IMPORTSTRUCT({ 'I' => 123,
                     'C' => 'AbCdEf',
                     'STR' =>  'The quick brown fox ...',
                     'XSTR' => pack("H*", "deadbeef")});

 # invoke the Function Module and then play with the results
 $fs->invoke;
 $stderr.print "RESPTEXT: #{fs.RESPTEXT.inspect}\n"
 $stderr.print "ECHOSTRUCT: #{fs.ECHOSTRUCT.inspect}\n"
 print STDERR "RESPTEXT: ".Dumper($fs->RESPTEXT)."\n";
    ok($c eq 'AbCdEf');
 print STDERR "ECHOSTRUCT: ".Dumper($fs->ECHOSTRUCT)."\n";

 # cleanup
 $conn->disconnect;

Config file format is the same as for Ruby - refer to the sap.yml file in the download:

ashost: ubuntu.local.net
sysnr: "01"
client: "001"
user: developer
passwd: developer
lang: EN
trace: 2

Test it out - and give your feedback. The best place would be to carry on the discussion through the Forums.

Special thanks go to:

• Ulrich Schmidt for fielding all my questions, and the whole of the NW RFC Team (NW AS ABAP Connectivity), for their support, and quick response.
• Olivier Boudry - building and testing
• and lastly (but by no means least) Craig Cmehil for tirelessly getting people together and making it all possible.

Notes/Updates:

isusr = rfc.discover("SUSR_CHECK_LOGON_DATA")
isusr.AUTH_METHOD.value = "E"
isusr.AUTH_DATA.value = "p:ompka\\piers"
isusr.EXTID_TYPE.value = "NT"
rfc.call(isusr)
puts "RESULT: "

# access an interface parameter value
print "TICKET:             #{isusr.TICKET.value.to_s}\n"
ticket = isusr.TICKET.value.to_s

rfc2 = SAP::Rfc.new(:ashost => "192.168.1.2",
                   :sysnr  => 00,
                   :lang   => "EN",
                   :client => "010",
                   :mysapsso2 => ticket,
                   :trace => 1
       )

This code snippet demonstrates using one RFC connection to generate login tickets for another - a very useful trick for brokering connections within an external application. The login tickets in the standard RFC are carried in an RFC_STRING (isusr.TICKET) type parameter.

Note: Thanks to Gregor for pointing this out.

Steps

• Follow the steps outlined in Ruby, Ruby on Rails, and SAP Web Services Integration upgrading sapwas to at least version 0.06, and sap4rails to at least version 0.05, making sure that the soap/rfc handler works correctly.
• Create the Virtual Interface, Web Service Definition, and Web Service Config to expose the UserAdmin Function Modules
• Modify app/models/sap_user.rb to point to the new Web Service definition

Create the SAP Web Service

• Z_BAPI_USER_GETLIST
• BAPI_USER_GET_DETAIL
• BAPI_USER_LOCK
• BAPI_USER_UNLOCK

Activate this, and then create a Web Services definiton - again, using SE80, go to the Enterprise Services tab, and create a Web Services definition called Z_USERADMIN - referencing the previously activated Vitual Interface Z_USERADMIN.
Finally - activate this in the ICF configuration (SICF), by using transaction WSCONFIG, referencing the Web Service definition Z_USERADMIN created above.
There is an excellent discussion of the details of this process by Thomas Jung, here, and here.

Modify model sap_user.rb

require_gem "sap4rails"

class SapUser < SAP4Rails::WS::Base

# You must define a list of RESOURCES to preload
   resources "http://seahorse.local.net:8000/sap/bc/srt/rfc/sap/Z_USERADMIN"
...

Unicode!

Round Up

...
[SapUser] missing_method: Z_BAPI_USER_GETLIST
[SapUser] ifaces: ["SUSR_USER_LOCKSTATE_GET", "BAPI_USER_GET_DETAIL", "BAPI_USER_UNLOCK", "BAPI_USER_LOCK", "Z_BAPI_USER_GETLIST"]
in check connect...
Think Im connected - lets check ...
RFC PING[]...
Something wrong with connection(1) - do it again ...
new connection(2) ...
allready connected ...
[SapUser] missing_method: Z_BAPI_USER_GETLIST
[SapUser] ifaces: ["SUSR_USER_LOCKSTATE_GET", "BAPI_USER_GET_DETAIL", "BAPI_USER_UNLOCK", "BAPI_USER_LOCK", "Z_BAPI_USER_GETLIST"]
in check connect...
Think Im connected - lets check ...
RFC PING[true]...
...

Here you can see the first RFC_PING return nil, and the second after reconnect return [true].

require "SAP/WAS"

@was = SAP::WAS.new(:url => "https://seahorse.local.net:8443/sap/bc/srt/rfc/sap/Z_RFC_READ_REPORT_01",
                    :lang   => "EN",
                    :client => "010",
                    :user   => "developer",
                    :passwd => "developer",
                    :trace  => true)

# get a list of users
irep = @was.RFC_READ_REPORT
irep.program.value = 'SAPLGRAP'
irep.call()
puts "qtab no rows are: #{irep.qtab.rows.length.to_s}"
puts "qtab rows are: #{irep.qtab.rows.inspect}"

sapwas fully integrates with sap4rails as an alternative driver for accessing either RFCs or SAP SOAP based Web Services, and is available here.

SAP Web Services vs RFC?

Other than curiosity, there is another motivation for trying this out - Since there has been discussion of late on the merits of RFC and Web Service technology such as SOAP, I thought that inorder to do the subject justice I would do some further (tangible) investigation.

To me, the most obvious way to draw a comparison, is to develop comparable examples of each, with the only difference being the substitution of the technology in question.

This led to me focusing on a recent article I wrote: Ruby on Rails with AJAX, to use as a base line.

Activating the SAP Web Service support

If we take the example above (Ruby on Rails with AJAX), then the changes are as follows:

• Install sapwas (version 0.02+)
• Upgrade sap4rails (version 0.04+)
• modify the SapUser model
• set your Rails configuration

Install sapwas

Download either the source distribution, or the gem file by following the sapwas project download links. Gem files are easier to deal with - all you need to do is:

gem install sapwas-<version>.gem

And its done (use gem uninstall to remove if its there allready).

You will probably need to install http-access2 inorder to get the basic authentication working correctly. This is a requirement of the SOAP4R library.

Upgrade sap4rails

Download either the source distribution, or the gem file for sap4rails by following the project download links. First remove the old version, and install the new:

gem uninstall sap4rails
gem install sap4rails-<version>.gem

If you have used the source distribution previously, then you will have to manually remove the previous one, and install again (the usual ruby setup.rb dance - gems are soo much easier :-).

Modify the SapUser model

In the Rails application, edit the app/models/sap_user.rb, and change the super class for SapUser:

class SapUser < SAP4Rails::WS::Base
...

Set your Rails configuration

Modify the config/sap.yml file - you really should only need to add in the :url line depicted below, but check anyway:

  client: "010"
  url: "http://seahorse.local.net:8000/sap/bc/soap/rfc"
  user: developer
  passwd: developer
  lang: EN

note on WAS configuration

You must ensure that /sap/bc/soap/rfc is configured/activated correctly in transaction SICF.

Go!

Once you have completed these changes, you can then test the Rails application as described in Ruby on Rails with AJAX - it should function in exactly the same manner - wasn't that easy!

Now you have it working - I'll leave you to draw your own conclussions on it's merits :-)

iter = 10
rfc = SAP::Rfc.new(...)
# look up the interface definition for an RFC
i = rfc.discover("STFC_CHANGING")
i.counter.value = 0
iter.times {|cnt|
  puts "\n\n\n\n\nITERATION #{cnt + 1}\n\n\n\n"
  i.start_value.value = cnt
  rfc.call(i)
  puts "RESULT: #{i.result.value}  COUNTER: #{i.counter.value}"
}
# close the connection
print "close connection: ", rfc.close(), "\n"

To me - this kind of interest shows that Ruby on Rails is making a step change in it's progress through the world of IT, where it will likely start penetrating into the Enterprise software development market.]]> http://www.piersharding.com/blog/archives/2006/10/sap_and_rails_i.html http://www.piersharding.com/blog/archives/2006/10/sap_and_rails_i.html rails Tue, 10 Oct 2006 07:58:23 +0000 Jabber and IM is very much in the ascendancy at the moment, thanks to Google Talk which uses the very same XMPP protocol for messaging.

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

XMPP

Jabber

• 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.

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.

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

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.).

SCOT Configuration

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
        Usage: smtpcomponent.rb [-h -s -p -a -c -r -q]
        Options
          -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
  
piers@gecko:~/code/ruby/smtpcomp$ 

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).

What happens?

To show what happens, the following transcript traces first an R/3 email -> Jabber flow, and then the reverse. In this example, even though the sending R/3 user account is DEVELOPER, I have configured the INET mail address of the R/3 user to be piers@seahorse.local.net, in the user communication section of address details (transaction SU01).

This log section shows the SMTP transcript, the translation of addresses, and then the final construction of an IM message (in XML).

COMM: EHLO seahorse.local.net

COMM: MAIL From:

DID a 250 for MAIL 
COMM: RCPT To:

DID a 250 for RCPT 
COMM: DATA

Message: Is it ready yet!I've been waiting all day blah blah blah ....

DID a 250 for data 
COMM: QUIT

An email was created in R/3 by going to the SAP Office assistant (transaction SO01).

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 piers@gecko.local.net/Psi to piers@sapsmtp.local.net () 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.

Rails and AJAX

Installation Requirements

gem install sap4rails-<version>.gem

UserAdmin

The following RFCs are used:

• BAPI_USER_GETLIST - list users, and their address details
• BAPI_USER_LOCK
• BAPI_USER_UNLOCK

BAPI_USER_GETLIST is not quite enough. This, I have had to wrap in another function module and also modify the results table to include the lock status information of users.
Create a new function module called Z_BAPI_USER_GETLIST, and make sure that you activate it for RFC on the attributes tab (in SE37) (code).
Create a new structure called ZBAPIUSNAME, and include the two structures BAPIUSNAME, and USLOCK like this .
Make sure that you activate the structure.

The code and interface needs to be completed like this:

FUNCTION Z_BAPI_USER_GETLIST.
*"----------------------------------------------------------------------
*"*"Local Interface:
*"  IMPORTING
*"     VALUE(MAX_ROWS) TYPE  BAPIUSMISC-BAPIMAXROW DEFAULT 0
*"     VALUE(WITH_USERNAME) TYPE  BAPIUSMISC-WITH_NAME DEFAULT SPACE
*"  EXPORTING
*"     VALUE(ROWS) TYPE  BAPIUSMISC-BAPIROWS
*"  TABLES
*"      SELECTION_RANGE STRUCTURE  BAPIUSSRGE OPTIONAL
*"      SELECTION_EXP STRUCTURE  BAPIUSSEXP OPTIONAL
*"      USERLISTLOCK STRUCTURE  ZBAPIUSNAME OPTIONAL
*"      RETURN STRUCTURE  BAPIRET2 OPTIONAL
*"----------------------------------------------------------------------
*
data:
  LOCKSTATE LIKE  USLOCK,
  userlist like bapiusname occurs 0 with header line.

  refresh userlistlock.


  CALL FUNCTION 'BAPI_USER_GETLIST'
    EXPORTING
      MAX_ROWS              = 0
      WITH_USERNAME         = with_username
    IMPORTING
      ROWS                  = rows
    TABLES
      SELECTION_RANGE       = selection_range
      SELECTION_EXP         = selection_exp
      USERLIST              = userlist
      RETURN                = return
            .

  loop at userlist.
    move-corresponding: userlist to userlistlock.
    if userlistlock-firstname = space.
       userlistlock-firstname = userlistlock-username.
    endif.

    CALL FUNCTION 'SUSR_USER_LOCKSTATE_GET'
      EXPORTING
        USER_NAME                 = userlist-username
      IMPORTING
        LOCKSTATE                 = lockstate
      EXCEPTIONS
        USER_NAME_NOT_EXIST       = 1
        OTHERS                    = 2
              .

    move-corresponding: lockstate to userlistlock.
    append userlistlock.

  endloop.

ENDFUNCTION.

Activate the function module and test it.

The Rails part

The full application can be downloaded from here - but what I'd like to do is quickly describe the meat of what had to be done to get this type of application working.

Config - sap.yml

As described in the RadRails blog, you need to adjust the configuration in config/sap.yml to point to your SAP system:

development:
  ashost: 10.1.1.1
  sysnr: "00"
  client: "010"
  user: developer
  passwd: developer
  lang: EN
  trace: "1"
...

Model - sap_user.rb

The SapUser object now inherits from the new SAP4Rails::Base class. This serves to automatically take care of managing RFC connections based on the config done above. The two main class methods for use are function_module, which allows you to declare what RFCs you want to use, and parameter which is a helper method for declaring attributes of a SapUser (or any other Model object).
In the interests of simplifying the application, by reducing the amount of ABAP code to be written, and the number of RFC calls to be made, I have in a way "cheated", with the arrangement of methods defined in SapUser. Instead of having a SapUser#find method, I rely on the use of SapUser#find_all and SapUser#find_cache to reduce a series of SapUser searches down to one RFC call only. In reality this is probably not good practice, but it suits for this example.

Read the code comments below for further details:

require_gem "sap4rails"

class SapUser < SAP4Rails::Base

# You must define a list of RFCs to preload
  function_module :Z_BAPI_USER_GETLIST,
	                :BAPI_USER_LOCK,
	                :BAPI_USER_UNLOCK

# You must define a list of attribute accessors to preload
  parameter :last, :first, :userid, :locked

# do your attribute initialisation for each SapUser instance
	def initialize(last, first, userid, locked)
	  @last = last
	  @first = first
	  @userid = userid
	  @locked = locked
	  @changed = false
	end

# what is the lock state
	def locked?
	  return self.locked ? true : false
	end

# on #save - flip the lock state of the SapUser, calling the 
# appropriate RFC to do it
  def save()
    RAILS_DEFAULT_LOGGER.warn("[SapUser]#save what did we get: " + self.inspect)
   
    if self.locked?
      SapUser.BAPI_USER_LOCK.reset()
      SapUser.BAPI_USER_LOCK.username.value = self.userid
      SapUser.BAPI_USER_LOCK.call()
    else
      SapUser.BAPI_USER_UNLOCK.reset()
      SapUser.BAPI_USER_UNLOCK.username.value = self.userid
      SapUser.BAPI_USER_UNLOCK.call()
    end

    # just so something happens ...
    return true
  end

# one RFC call to get them all
  def self.find_all
    RAILS_DEFAULT_LOGGER.warn("[SapUser]#find_all ")
    SapUser.Z_BAPI_USER_GETLIST.reset()
    SapUser.Z_BAPI_USER_GETLIST.with_username.value = 'X'
    SapUser.Z_BAPI_USER_GETLIST.call()
    users = []
    SapUser.Z_BAPI_USER_GETLIST.userlistlock.rows().each {|row|
		  next if row['FIRSTNAME'].strip.length == 0
		  state = nil
		  if row['WRNG_LOGON'] == "L" || 
                     row['LOCAL_LOCK'] == "L" || 
                     row['GLOB_LOCK'] == "L"
		    state = true
	          else
		    state = false
		  end
		  users.push(SapUser.new(row['LASTNAME'], 
			                 row['FIRSTNAME'], 
				         row['USERNAME'], 
					 state))
		}
    return users
  end

# find a user base on the results of a SapUser#find_all
  def self.find_cache(user, cache)
    RAILS_DEFAULT_LOGGER.warn("[SapUser]#find_cache: #{user} ")
    cache.each{|row|
	  return row if user.strip == row.userid.strip
    }
  end

# get a list of all the locked users
  def self.find_locked
    RAILS_DEFAULT_LOGGER.warn("[SapUser]#find_locked ")
    locked = []
    find_all().each{|user|
	  locked.push(user) if user.locked
    }
    return locked
  end

# get a list of all the unlocked users
  def self.find_unlocked
    RAILS_DEFAULT_LOGGER.warn("[SapUser]#find_unlocked ")
    unlocked = []
    find_all().each{|user|
	  unlocked.push(user) unless user.locked
    }
    return unlocked
  end
end

Controller - lock_controller.rb

class LockController < ApplicationController

# gnerate the starting user lists, and hand off to the default list view
  def list
    RAILS_DEFAULT_LOGGER.warn("[LIST] Parameters: " + @params.inspect)
    @locked_users = SapUser.find_locked()
    @unlocked_users = SapUser.find_unlocked()
    RAILS_DEFAULT_LOGGER.warn("[LIST] of Locked: " + @locked_users.inspect)
    RAILS_DEFAULT_LOGGER.warn("[LIST] of UNLocked: " + @unlocked_users.inspect)
  end

# check through the list of locked users in the locked sortable_element box
# and set their locked state in necessary
# on completion - render the partial locked_users
  def set_locked
    RAILS_DEFAULT_LOGGER.warn("[SET_LOCKED] Parameters: " + @params.inspect)
    @locked_users = []
    cache = SapUser.find_all()
    if @params['locked_box']
      @params['locked_box'].each {|locked|
	  next if locked.length == 0
          user = SapUser.find_cache(locked, cache)
	  next if user.first.strip.length == 0
	  if user && ! user.locked?
  	    user.locked = !user.locked?
   	    user.save
          end
          @locked_users.push(user)
      }
    end
    render :partial => 'locked_users', :object => locked_users
  end

# exact opposite/the same as set_locked
  def set_unlocked
    RAILS_DEFAULT_LOGGER.warn("[SET_UNLOCKED] Parameters: " + @params.inspect)
    @unlocked_users = []
    cache = SapUser.find_all()
    if @params['unlocked_box']
      @params['unlocked_box'].each {|unlocked|
	  next unless unlocked.length > 0
	  user = SapUser.find_cache(unlocked, cache)
	  next if user.first.strip.length == 0
	  if user && user.locked?
	    user.locked = !user.locked?
  	    user.save
  	  end
	  @unlocked_users.push(user)
      }
    end
    render :partial => 'unlocked_users', :object => unlocked_users
  end

# called by the rendering action of the partial locked_users
  def locked_users
    RAILS_DEFAULT_LOGGER.warn("[LOCKED_USERS] of Locked: " + @locked_users.inspect)
    @locked_users
  end

# called by the rendering action of the partial unlocked_users
  def unlocked_users
    RAILS_DEFAULT_LOGGER.warn("[UNLOCKED_USERS] of UNLocked: " + @unlocked_users.inspect)
    @unlocked_users
  end

end

Views

layout/application.rhtml

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta http-equiv="Content-type" content="text/html; charset=utf-8" />
    <title>User Administration:  <%= controller.controller_name %></title>
    <meta http-equiv="imagetoolbar" content="no" />
    <%= stylesheet_link_tag "administration.css" %>
    <%= javascript_include_tag "prototype", "effects", "dragdrop",
                       "controls" %>
  </head>

  <body>
  <div id="container">
    <div id="header">
    <div id="info">
      <%= link_to "home", :controller=> "/lock", :action => 'list' %>
    </div>
      <h1><%= link_to "UserAdmin - #{controller.controller_name}", :controller => "/lock" %>
        </h1>
    </div>
    <div id="content">
      <h2><%= @page_heading %></h2>
      <%= @content_for_layout %>
    </div>
  </div>
  </body>
</html>

lock/list.rhtml

The two most important things in list are the two container div tags - unlocked_box and locked_box. These in turn, have a corresponding partial (unlocked_users, and locked_users), that are responsible for generating the dragable user items.

<% @heading = "User Admin - Lock/UnLock" %>

  <div id="user-admin">
    <div id="unlocked" class="dropbox">
      <h3>Unlocked Users</h3>
      <div id="unlocked_box">
        <%= render :partial => 'unlocked_users', :object => @unlocked_users %>
      </div>
    </div>

    <div id="cnt-locked" class="dropbox">
      <h3>Locked Users</h3>
      <div id="locked_box">
        <%= render :partial => 'locked_users', :object => @locked_users %>
      </div>
    </div>
    <br clear="all" />

  </div>

lock/_unlocked_users.rhtml

the partial unlocked_users either displays a place holder element if there are no users, or calls the render of unlocked_user for each user. It also uses the AJAX function sortable_element which dictates what div container holds the sortable drag and drop elements, and what actions to take when an event is fired with them. This is how we trigger the call to the set_unlocked or set_locked action of the list controller for updating the individual "boxes" of users.

<% if unlocked_users.empty? %>
  <div class="target">  You have no Unlocked SAP Users.... </div>
<% else %>
  <%= render :partial => 'unlocked_user', :collection => unlocked_users %>
<% end %>

<%= sortable_element "unlocked_box",
  :update => "unlocked_box",
  :url => {:action=>'set_unlocked'},
  :tag => 'div', :handle => 'handle', :containment => ['unlocked_box','locked_box'] %>

<%= sortable_element "locked_box",
  :update => "locked_box",
  :url=> {:action=>'set_locked'},
  :tag => 'div', :handle => 'handle', :containment => ['locked_box','unlocked_box'] %>

lock/_unlocked_user.rhtml

the partial unlocked_user renders a dragble_element for each SapUser.

<div id="unlockeduser_<%= unlocked_user.userid %>" class="dragitem">
  <h4 class="handle"><%= unlocked_user.userid %></h4>
  <p><%= unlocked_user.last + ", " + unlocked_user.first %></p>
</div>
<%= draggable_element "unlockeduser_#{unlocked_user.userid}" %>

lock/_locked_users.rhtml

the same as for the partial unlocked_users

<% if locked_users.empty? %>
  <div class="target">  You have no Locked Users ...  </div>
<% else %>
 <%= render :partial => 'locked_user', :collection => locked_users %>
<% end %>

<%= sortable_element "unlocked_box",
  :update => "unlocked_box",
  :url => {:action=>'set_unlocked'},
  :tag => 'div', :handle => 'handle', :containment => ['unlocked_box','locked_box'] %>

<%= sortable_element "locked_box",
  :update => "locked_box",
  :url=> {:action=>'set_locked'}, 
  :tag => 'div', :handle => 'handle', :containment => ['locked_box','unlocked_box'] %>

lock/_locked_user.rhtml

the same as for the partial unlocked_user

<div id="lockeduser_<%= locked_user.userid %>" class="dragitem">
  <h4 class="handle"><%= locked_user.userid %></h4>
  <p><%= locked_user.last + ", " + locked_user.first %></p>
</div>
<%= draggable_element "lockeduser_#{locked_user.userid}" %>

In config/routes.rb add:

 map.connect '', :controller => "lock", :action => 'list'
 

This makes sure that any requests to the root of the server eg. http://localhost:3000, are forwarded onto the list action of the lock controller.

firing Up

Start the Rails WEBrick server by running the script:

ruby scripts/server

When you connect to http://localhost:3000 (there will be an inital delay as sap4rails caches the RFC calls), you should get a screen that looks like this

A Flash movie of this in action can be seen here.