Technical View on SAP Community Missions
The SAP Community published a gamification feature with user badges and missions such as “Hello World!”, “Blogger”, and “Solver”. Caroleigh Deneen already wrote about it. Since I was involved in the development of this feature as a software architect, I would like to share some technical aspects.
The Engine
The most important building block, the centerpiece, of this feature is the SAP Cloud Platform Gamification. This system runs the SAP Community-specific gamification rules to:
- Assign missions to users
- Update mission progress
- Complete missions and assign badges
The SAP Cloud Platform Gamification manages all missions, badges, and the related business logic in one central point. The system also stores the progress and achievements.
The rules to handle the events are written in Drools:
updateAPIv1.givePoints($playerid, 'Experience Points', 1, 'Task completed.');
updateAPIv1.completeMission ($playerid, 'Troubleshooting');
updateAPIv1.addBadgeToPlayer($playerid, 'Champion Badge', '1. place');
update(engine.getPlayerById($playerid));There are additional landscapes for development and testing. The test cases are based on automated JUnit tests.
Events, Events, Events
The service is connected to the SAP Community’s messaging system and receives messages about user activities such as “publish blog post”, “liked blog post”, “follow user” etc. These messages are processed one after another by SAP Cloud Platform Gamification and the involved users are updated.
If eventually a user mission is completed, the Gamification Service will publish a message to notify other systems that need this kind of update. The message is, for instance, relevant for the activity stream and for the notification service.
Because of this messaging approach the involved systems are loosely coupled. The systems do not even know about each other. The message routing to the gamification system could be changed easily without any change to the overall architecture.
API Integration and Caching
The information in SAP Cloud Platform Gamification about a user’s earned badges and the proceeding in-progress missions is available to other applications via an API. The API responses are cached and regularly updated by the client systems for performance reasons. I.e. after receiving a badge it could take a couple of minutes until the user eventually can see them.
Eventual Consistency
The user profiles (https://people.sap.com) run on several server instances with a shared cache that also includes the missions and badges from the Gamification Service. The cache is updated for individual users if their data is requested and if the cache entry is too old. For performance reasons, however, the cache update is executed asynchronously in the background and the result will only be visible for the next requests, i.e. the current request gets still the old cache data. But don’t worry, the data will eventually become consistent. The cache update will be improved soon with an event-based mechanism.
Thanks for posting this and sharing a bit about what technologies have been used to re-introduce a feature that the old SCN platform provided.
I definitively learned something as I never heard about "Drools" before, so that's a big plus for any blog post in my books (learning something that is).
Likewise, I do appreciate the strong structuring of the post, even though I feel it lacks a proper end that closes up the topic.
However, there is one aspect of this post that I find worrying. It's the absence of a point of view on how this feature and the specific choice of architecture supports the SAP Community in regaining trust and traction and how it will be good for the SAP community and eco-system in general. I guess, what I am asking is the architectural context for the decision making that led to the architecture.
Usually, that is - next to technological feats - what's interesting and important about architecture: the impact on people's lives and experiences. And that part, unfortunately, did not get any coverage in this article.
Caroleigh's blog post does reintroduce the general idea behind missions, but it does not (and really shouldn't) go into how this idea is implemented and how its architecture works towards the goals of the idea.
From my point of view, the SCP architecture, development and management team could reduce the disconnect from the member base by communicating the concepts and expected impacts more openly.
Hello Lars,
many thanks for your comment and interest in the SAP Community.
The development team decided to implement this new feature with the SAP Cloud Platform Gamification because it provides sophisticated gamification concepts that match our requirements. Another big advantage of this solution is the fact that most SAP Community applications also run on the SAP Cloud Platform. #EatOwnDogFood
The blog post also describes the messaging integration. This is a general part of the SAP Community architecture, which was not introduced in particular for this feature.
Thus, the decision for the SAP Cloud Platform Gamification and the messaging integrating was a natural fit to the existing SAP Community and eco-system.
Thanks a lot, Kai!
IMHO we need more blogs like this one, because they show what's going on behind the scenes in the community, which is usually very non-transparent to the end users and at the same time highly underrated. Lastly, it's of great personal interest for me because as a fellow developer, I love to know how stuff works and why stuff presumably does not work when accessed from the impenetrable fortress I work in (public sector).
Cheers, Lukas