Skip to Content

Trip to Mastering SAP Technologies – Demo Jam and all that

Day(s): Wednesday – Saturday | Sunday Sunday Sunday | Monday | Tuesday

After the Mastering SAP Technologies international speakers dinner Saturday I spent my first night sleeping in the Southern hemisphere.  Somewhere between home and here I had picked up some kind of bug, or was stressed out and run down from the travel, and my jaw felt like it was going to erupt. With a week of conference work and some down time ahead, this was an unwelcome distraction from what I would have preferred.

As we had time in the morning before the Inside Track day started, it was a short walk over to the Art Gallery of New South Wales to see local and global culture, the highlight being a one-hour guided tour through many of the important local artists and styles.  Very much a different type of audience than the zoo the day before, and despite the day being a rainy Sunday, not a crowded feeling (except when trying to find refreshments).

With such a huge arrangement of the original gallery and expansions, even choosing a select few areas to visit took well over 3 hours, and my arrival at the user sessions back at the conference hotel was not quite prompt.  I managed to sit in on several sessions, many from speakers I know from the Mentor program and ASUG, and a few new faces.  Being rundown, I wasn’t as engaged as I might have been, and I was surprised how much I missed from not picking up the local accents that quickly.  The reverse seems to be true, as our interactions with others such as restaurants indicate the Australians don’t follow my American accent that well sometimes either.


A few highlights and/or bullet points from the first full session I sat in on “Workflow” with Sue Keohan and Matt Harding

“[You could] use [Microsoft] Sharepoint as a workflow”, Matt Harding said, if I caught him correctly, meaning there are numerous tools that serve a similar purpose for business continuity. The toool chosen may depend on what is already installed, where there are core competencies, or simply the whim of the decision makers.  (As it turns out, an on site vendor booth promises “The Power of SAP wuth the familiar and … of Microsoft”).

“[SAP] Streamworks” is free, said Matt, indication that there are basic versions of this newish SAP product, and there is an enterprise version.  There was discussion about whether Streamworks is enterprise ready, and how to locate the primary SAP web access for the tool (Google it).

Another discussion point was verifying personnel (HR/HCM) records between the official system and the workflow system, given they may not even be from the same vendor.  One commenter suggested PI data flows between the HR system and workflow, to capture adds, changes and deletes in the organization chart.  Sue Keohan suggested methods of adding meta data to the workflow repostory, as approvals path may not strictly follow hierarchical lines.  I had a question on what the auditors thought about this, but didn’t get through the buzz that was going.  Maybe Sue has an answer, or someone else, after. 

Sue also spoke about “BRF+”, with  Karsten [] being the recognized expert.  I would also suggest Peter McNulty, who has presented on this topic in other conferences I have attended.  The Business Rules Framework would be an add-on, or supplementary method of capturing the workflow paths in a specific repository.

There was a question about the differences among workflow engines, configuration and implementations across different SAP platforms, products and version.  Sue mentioned that some systems, such as CRM and SRM, had so-called “enhanced engines” and that templates for different purposes might vary greatly.  But I gathered the overal effect was minimal, so that knowledge transfer between systems was not too complex. I’d speculate that trying to combine or resolve workflows from two distinct sources, as may happen during a merger for instance, would not be trivial, and the decision might be that reimplementation would be the simplest choice.

Code Exchange

Tony Duncan (from ?) facilitated the discussion on SAP Code Exchange.  Since I’d been on a moving conference session with Rui Nogueira before SAP TechEd 2010, I was clued in to a lot of the infrastructure, design, methods, purpose and legal ramifications of the repository.  But I learned a bit more in this context, and while I’m not likely to be a contributor or even participant, the impact of this will increase.

People discussed the licensing model used by checked-in code, and while there is a terms-of-use agreement encompassing the site, each project may have its own distribution restrictions, such as GNU or MIT (though I would throw in BSD, Apache, Perl and maybe a few others).  Thus, commercial use is probably acceptable in all cases, but you’d do well to read the fine print.  And reselling what you get for free isn’t going to look good if someone traces the genealogy to Code Exchange.

Another question was the source of the source, so to speak, as one commenter asked if code was vetted by someone before being checked in.  In other words, if a developer wrote code for a customer under contract, then turned around and “contributed” such code to the repository, is that acceptable?  Given plagiarism discussions we’ve seen on SCN, this seems an important question: do the Code Exchange project teams have the legal right to share what they distribute, or not, and what are the consequences if someone claims prior ownership?

Also, once Code Exchange has gotten to a certain size, how does a casual user search for solutions, what are the standards for documentation, and what are the typical parameters for a project?  I don’t think any of those are answerable fully yet, though it’s been typical for projects to be small and standalone.

In the context of “user-contributed” code, the audience talked about the success of SAPlink as a useful piece of work that built by and for the community.  Although I’m aware of it, I’m unable to describe it beyond “if Thomas Jung worked on it, it’s good.”



Sorry, but this topic is over my head (POWL = “Personal Object Work List”, per Google).  I feel overwhelmed when leading edge development terms are discussed, particularly when the technologies are something I have no direct, or even indirect experience with.  But it’s fascinating to hear the conversations, try to understand the decisions people are faced with, and may try to add a note of reason to the topic.

The tool is “not intuitive”, according to one developer, based on his experience. I didn’t hear much dissent from the group, though I think this may be a case of familiarity breeds contempt.

Netweaver LIVE was a new term (to me), dropped by Thomas Jung.  A short Google search found a blog by Yariv Zur, which I’d look at.   Maybe when I have more time.





The last session of the Inside Track was planned to be on Mobility, led by Kevin Benedict, but Graham Robinson drafted a few others to facilitate the discussion since he wasn’t available.  Here again, this is a subject I am familiar with (to a small extent) but the chat went quickly into the deep end of the pool, with claims that iPhones are the majority out there (oh, sorry, we ignored Blackberrys), and threads on which software platform or tools to use, from Gateway to the renamed SAP Unwired Platform to an impenetrable discussion of JSON versus Odata.  It all sounds like a horror movie to me.

The architecture of Gateway became a little clearer to me, particularly around the compatibilities with specific SAP versions, and even more precisely, the licensing and patching requirements. It sounds like “salesperson will call”, similar to why I’ve generally disliked the Streamwork direction.

The most important takeaway from that session was having a “return on investment of 18 months or less” for a mobile technology project now, since the landscape is changing so rapidly.  Within 60 days from now, when SAP rolls out new products at Sapphire, the rules will change yet again.


Demo Jam


I missed the beginning of Demo Jam, after taking a much needed short rest, so the crashes or misfires of the first contenders went unrecorded. Having not been a big fan of listening to developers wax enthusiastic about yet another one-off tangent, I have not seen anything at one of these that would be a “lessons learned” I’d share with my management or peers.  The contenders are intense about their rivalries, their technologies, and their moxie, which is testament to how SAP has grown in the community space.

[Once I can upload videos I took, they will be at the end.]































You must be Logged on to comment or reply to a post.
  • Jim,

    Thanks for the great recap, but there is some incorrect information here regarding Code Exchange licensing that could have bad consequences, so I feel the need to give my point of view.

    You say: “People discussed the licensing model used by checked-in code, and while there is a terms-of-use agreement encompassing the site, each project may have its own distribution restrictions, such as GNU or MIT (though I would throw in BSD, Apache, Perl and maybe a few others).  Thus, commercial use is probably acceptable in all cases, but you’d do well to read the fine print.”

    I believe the contrary is actually true. When you agree to the Code Exchange Terms of Use (linked below), you agree to license any software you upload under the terms of the Netweaver Developer License Agreement (NDLA – also linked below). Further, the Code Exchange Terms of Use specifically ban uploading code under any open source license, including the GPL, MIT, Apache, and BSD licenses (Section 6B). My discussions with Rui and others have led me to believe that the Code Exchange TOU requires that code uploaded to Code Exchange be licensed under the terms defined in the NDLA and only those terms.

    The NDLA also seems to prohibit any redistribution of code except on Code Exchange. This would seem to preclude commercial use (or indeed redistribution anywhere but on Code Exchange) of any code on Code Exchange without first obtaining a separate license allowing this redistribution from SAP or from the copyright-holder of the code.

    As usual, my disclaimer: I am not a lawyer, but I did go through the pain of reading these multiple versions of these two documents in detail multiple times as I tried to decide whether I wanted to participate in Code Exchange. The Code Exchange TOU is now relatively readable. The NDLA has a long way to go. Both documents are intertwined, and someone signing up for Code Exchange should be sure to read and understand both documents, as that person will be accepting some significant restrictions while giving a very permissive license to SAP.

    Relevant links:

    Code Exchange Terms of Use –

    Netweaver Developer License Agreement –


    • Ethan:  Thanks for doing the research.  I was repeating what I heard in the session, and did not verify the accuracy.  I’ve never read the Code Exchange terms, and even if I had, I may not have been able to state what is allowed or not.


      • Hi Jim,

        No problem, and sorry that this may have sounded adversarial. It was not intended in that way. This is an area of SAP’s community interaction that could use a lot of work at the moment and I’m quite worried about what it means for the long term prospects of a healthy developer community for software that interacts with SAP’s software.

        It’s unfortunate that this (it seems) incorrect information was shared in the session. Hopefully this goes a little way towards setting the record straight. There is a lot of misconception among developers about what SAP believes you are allowed to do with SAP software and web services. Hopefully SAP will continue to clarify things (as Rui has done a great job of doing) before there is a really big issue.