interfaces. Users are faced with information overload, keyboard
driven input, and there is only a handful of experts that really know
how to take advantage of the features provided. The problem that
organizations face is that the common tasks that need to be performed
are small and task orientated, and would be better served by a
specific interface rather than a generic one. Reducing the complexity
for the users and training costs.
Dan Mcweeny presented a case study at JavaOne from Colgate-Palmolive where they
did just that. Because of the complexity of SAP, the technology
group was using a manual process to plan project time commitments,
with the very last step being data entry. Using Ruby On Rails and
SAP4Rails (an open source SAP integration library), the technology
group was able to create a specialized web 2.0 front end in 2 weeks to
automate the process - without prior knowledge of Ruby or Rails.
There are only two differences that the Rails developer needs to be
aware of: the model class extends the SAP4Rails::Base class rather
than the ActiveRecord::Base, proving a wrapper to SAP; and that the
interaction with SAP is not object orientation, instead being
functional. The model object provides the mapping between the
functional SAP system and Rails.
Using SAP4Rails with these two small changes, Rails developers now
have access to enterprise systems - and organizations can leverage
existing technology investments to create intuitive, easy to use web
2.0 based user interfaces quickly.