An Investigation: Atom-based
The Case For Atom
APIs For The Enterprise
Not All REST APIs Are Created Office
Using Atom With ERP and Scientist
Murray Spork, Juergen Schmerder
October 6, 23, 2009
Background (5 mins)
little bit of history
Atom overview (5 mins)
ERP and Atom (5 mins)
ERP and GData (5 mins)
Lessons learned (2 mins)
Open Issues (3 mins)
The (not-so) Hidden Agenda:
Evangelizing Support for Atom Within SAP
Atom as a standard platform access mechanism
ReST as the next “Tower of Babel”?
Instead - leverage network effects by adopting an existing and widely
Atom is in already in our ecosystem: Microsoft, IBM, Google, Oracle ....
Atom as exemplar for REST best practices
Understanding ReST can be difficult
Sometimes the benefits appear too abstract
- “What the heck is hypermedia as the engine of application state”??
ReSTless POX-over-HTTP misses many of the benefits of the Web Architecture
Atom embodies many ReST best practices
A Quiz To Start
Which of these technologies got its start in the world of Blogging?
A Quiz To Start
Which of these technologies got its start in the world of Blogging?
Answer = All of the above!
“Like XML-RPC and SOAP before, feeds and
publishing protocols were born in the blogopshere
and quickly moved beyond blogging.”
Where Did The Idea of Atom as a General
Purpose Web Syndication Format Come From?
Blog Syndication was a mess:
at least 4 different formats (RSS)
... let’s clean it up!
“SOAP seems too heavy-weight
for the Web - but do I have to
define my own protocol for
Atom sharing data over HTTP?”
“If we do a better job at separating “Feeds are basically lists of things...
form from content intermediaries what other kinds of information can
can do a lot more with feeds” we share via feeds besides blogs?”
--> Mashups Gdata (Google)
--> repurpose content Lotus (IBM)
Live Mesh (Microsoft)
… many others 7
Why Is Atom Used in APIs?
So what’s the big idea?
- Most structured data can naturally exposed as simple lists of things
(i.e. collections of entries)
- Collections may contain other nested collections
- Entries (within a collection) can link to other entries or other collections
- Entries (Resources) can represent anything: documents, business objects,
- Atom can do all of this in a “web-friendly” way (URLs for everything)
- Alternative representations of the same resource is possible (HTML, JSON, XML,
Atom Feeds: From Web 2.0 to Business Apps
Google Docs CICS
Del.ic.ious Open Gov - eGov.org
Europa build system (Eclipse)
Live Mesh Lotus Connections
Web 2.0 Enterprise
Bitsy & AtomDB
Google Data (Gdata):
A Family of Atom-based REST APIs
Source: Google Data Protocol http://code.google.com/apis/gdata/
The APIs that Google currently offer based on Atom and Atom Publishing Protocol
What is Atom?
IETF Atom WG Charter:
“Atom defines a feed format for representing and a protocol for editing Web
resources such as Weblogs, online journals, Wikis and similar content”
Things to note:
A syndication format: RFC-4287 (published December 2005)
A publishing protocol: RFC 5023 (published October 2007)
A “Web resource” can represent anything
Feed Data Model
Source:Beyond Blogging: Feeds in Action, Dave Johnson, 2007 Java One Conference
Service Document for Feed Discovery
Service ‣ Discovery - from a “well known
‣ Service Document structures
Feeds (= Collections) into
<?xml version="1.0" encoding='utf-8'?>
<atom:title>Address Book of User SCHMERDER</atom:title>
Atom and Enterprise Software - Scenarios
Scenario 1: Enterprise Application as Atom Publisher
Worklists (POWL) as Atom Feeds
Monitoring / Log Feeds that show recorded events & exceptions
“Business Objects” (BOR, AP, …) as Atom Collections and Entries *
⇒ Display data on any device that supports Atom/RSS
Scenario 2: Enterprise Application as Atom Consumer
Feed SAP data into non-SAP applications (and load it back in) *
River / Coghead
Scenario 3: Enterprise Application as Atom Publisher & Consumer
Peer-to-peer data synchronization
Distributed Data Management
* = Demo
Demo Scenario - Contact Feed
Disclaimer: We used Blue Ruby (a Ruby VM running on the ABAP Server) to
build the demo scenarios. This was for rapid prototyping purposes
only. Everything we show could be built in plain ABAP.
Address book feed powered by SAP Business Partner:
Contact persons for the current user (= BusinessPartners
of type “Person” that have a Relationship of type “Is
Contact Person for” to a BusinessPartner mapped to SY-
UNAME) are exposed as Atom Feed
The feed can be shown in any client that supports Atom
Clients can publish data to the feed
Demo Scenario - Contact Data Cleansing
A simple Data Cleansing Application using a Google Spreadsheet
Contact data (the feed from Demo 1) is uploaded to a Google Spreadsheet
Data is maintained in the Google Spreadsheed
Changed data is pulled back into the ABAP backend
Records that have not changed are ignored (using Etags)
Data is not re-imported if it has changed in the backend (using Timestamps)
Extra: Workflow linkage for event BusinessPartner.changed updates spreadsheet
when data changes in backend
Upload contact data
Update changed data
Download changed data
Lessons 1: ERP is a Rich Source for Feeds!
Most Documents (we often call them “Business Objects”) fit the Atom paradigms
of collections and entries
Collections are lists of objects, Entries are single objects or parts of objects
It’s always been good practice to record creation/change times and users
A lot of events are recorded as documents in the ABAP Backend
Syndication and Aggregation of different resources could help end-users
(e.g. Universal Work List as aggregation of Object Work Lists)
Publish / Subscribe totally underused
Etags and Timestamps allow for optimistic locking
Plus: many more examples here @ REST Summit 2009
If you have any more ideas - please talk to us!
Lessons 2: “Designing protocols is hard”
When Building Your REST API - Did You Think About.....
‣ encoding & escaping
‣ empty v not-present
‣ required v optional
‣ extensions & new formats
‣ caching & versioning
....didn't think so ;).
1. Bill deHora, “Snowflake APIs”, http://www.dehora.net/journal/2009/01/09/snowflake-apis/
Lessons 3: Links in Content is Good!
Atom is modular - at a minimum you should consider using atom:link in
your APIs (there are examples of APIs that do this - can we find any?)
<link rel="self" type="application/atom+xml"
<link rel="edit" type="application/atom+xml"
Atom is Far From Perfect or Even Complete
Missing from Atom
Filtering/ Searching/ Paging - use OpenSearch protocol
Support for hierarchies
– In-lining extensions for Atom (draft proposal from Oracle)
– Atom threading extensions
– Hierarchy IDs
Handling partial updates
POST or PATCH?
Diff/delta format needed?
Best practices for incorporating foreign markup and other data inside Atom feed
As children of atom:entry (Gdata model)
As children of atom:content with media type text/xml
Define custom media type
How to handle batch updates
Adopt the google batch model?
Is optimistic concurrency good enough? (we think so - for most things)
Can we make it easier to resolve conflicts?
– Microsofts FeedSync spec.
How do we tell clients how to add or update entries?
What replaces html:form?
Xform, RDF-Forms, WADL …?
But It Still Gets You 80% of the Way There
Gdata and the 80/20 Rule
“Google has definitively provided a simple but powerful enough API for
accessing their services. They do not want to solve 100% of all use cases
but rather provide a simple and uniform API for the majority (80%)”
Even considering the various open questions, Atom is good enough for a
lot of things already today.
Adam Bosworth Was One of the Earliest
Voices Pushing ATOM for Business Data
Adam Bosworth in 2005 - Lessons of last 10 years:
Open up your front end to wire formats and data that are easy open and
extensible (create network effects)
There is a serious change in computing happening - similar to the advent of the
web - around data
We need a standard simple protocol for data feeds
It needs to be sloppy (“democratize data”)
Needs to support updates
Has to scale - scale needs “stupidity” - complex things break - simple things
We have and answer in RSS 2.0/Atom - does for data what HTML did for content
Source: 2005 Keynote at MySQL
Juergen Schmerder Murray Spork
Office of Office of
Chief Scientist Chief Scientist
(now in IP&NW
- Solution Management)
Juergen joined SAP in 1999 and worked in Murray joined SAP Research in 2003 where he
various development projects in CRM, has lead several projects in diverse areas such
Netweaver and SAP Business ByDesign - both as model-driven engineering, Semantic Web,
in ABAP and Java. In 2007 he moved to Palo Web 2.0, introducing scripting languages into
Alto, California, where he joined the Office of the ABAP stack and network-enabled multi-
the CTO to lead the research project Blue enterprise business apps. He is passionate
Ruby - a Ruby VM, implemented in ABAP. He about any technology that facilitates
works part time as a project manager, part collaboration and decentralization and
time as an evangelist for scripting languages empowers “innovation at the edges” of an
and part time as a developer. organization.
Email: email@example.com EMail: firstname.lastname@example.org
About the Office of the Chief Scientist
The Office of the Chief Scientist (oCS) is
responsible for assuring SAP's awareness and
planning with respect to critical technologies,
especially those that are externally driven from
industry, academic institutions and customers. The
group, led by SAP Chief Scientist, Ike Nassi, is part of
the Office of the CTO (oCTO). oCS is not only
expected to think, project, and experiment, but also to
grow deep technical competencies ensuring an
ongoing ability to keep SAP at the forefront of the
The four main areas of work performed by oCS
Knowledge and Technology Scouting
Technology Vision and Guidance
Experimentation and Prototyping
For more information on the group and its work: