This document provides an overview of Blue Ruby, which combines the Ruby programming language with the ABAP application server. It discusses the goals of Blue Ruby, including enabling agile development and facilitating the creation of "glue code" and domain-specific languages. The technical architecture allows Ruby code to run inside the ABAP virtual machine for locality. Several demo applications are highlighted and next steps for collaboration on the SDN are outlined.
3. Blue Ruby – Who?
SAP Research Americas and China
Platform Research
Anne Hardy
Blue Ruby
Juergen Schmerder Murray Spork
(project lead)
Daniel Vocke Joseph Wang
Florian Reinhart
Su Yu
(student)
Kevin Schlieper
(student)
7. Programming Models Evolve
Faster Than Platforms
Timeless Software (Vishal Sikka)[1]
Best of both worlds: the flexibility of “glue code” alongside the “enterprise”
qualities of the ABAP stack
“The glue that binds”
There is no “one-size-fits-all” approach
Choose the right tool (language) for the job at hand
…scripting and dynamic languages are good for some things
…but coding core business logic in ABAP is not going away
Multi-language stacks
Flexibility in language choice whilst maintaining coherence
Industry trend: .NET now followed by Java
[1] Timeless Software: Part 2, Vishal Sikka https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/11837
8. A New Programming Model for Light-Weight
Application Extension Scenarios
Light-weight extensions: e.g. situational and departmental applications
Speed of development and flexibility are valued more than:
performance of runtime
lifecycle management
“Whether Ruby on Rails becomes prevalent
governance inside the enterprise or not - in the future
building Web applications inside the
enterprise will look a lot like it (RoR)”
Is it possible to “teach” the ABAP
-- paraphrasing Tim Bray
stack some of the tricks from
Ruby on Rails? For e.g.:
Convention over configuration
Simple things are simple - complex things are possible
Opinionated development
Do Not Repeat Yourself (DRY)
Test (or Behavior) Driven Development (TDD/ BDD)
Extendible Domain Specific Languages
9. Lazy developers want an embedded
scripting environment
Runtime benefits:
Locality: extension logic runs in the backend where the data and business
logic live
Make use of existing extension points for call-backs (i.e. ABAP calling script
code - e.g. BADIs)
Developer experience:
Simplify landscape: avoid maintaining separate infrastructure/ app servers
(e.g. Rails instances)
Don’t want to deal with low level issues such as connectivity, remoting
protocols
No need to worry about security, scalability, deployment etc.
Just get a developer account: log in, write code, test/execute
10. Why Ruby?
Could have chosen any scripting language - but:
Ruby is fun
Ruby is cool
Support for DSLs
Implementation reasons (principle of least surprise)
Enterprise Ruby developers are on the increase
In future could abstract
this into a “Dynamic
Language Runtime” (ala
the CLR in .NET) that
could support any
dynamic language
11. Potential Use Cases
Scenarios we have already experimented with:
Composing and adapting RFCs, BAPIs, Enterprise Services
Today’s demo
Exposing such composition via HTTP as RESTful services
Exposing POWL (worklist data) as an RSS/ATOM feed
Scripting Extentions to UI (e.g. floor plan manager)
Custom BAdI extensions
Batch-job scripting (e.g. Twitter alerts)
Other scenarios we will be exploring:
Bi-directional synching of business data via ATOM Pub
Test scripts for Business Objects/ Enterprise Services
Exploratory throw away prototyping
Have we missed any important use cases?
12. Vision: A Different Type of Developer
(to what SAP usually caters for)
Can Blue Ruby open up the ABAP stack to non-ABAP Developers?
In this context it is important to understand how the sandboxing concept
allows us to restrict what a Blue Ruby developer can do (but we will come
back to that)
A new persona
Line-of-business developers
Casual (non-professional) developers
Close to “the business” - have significant domain expertise
Programming may not be their full-time job - but they are comfortable doing
simple scripting (macros in Excel, Visual Basic in Office apps)