Folks,
I've thought quite some time about whether I should write this blog or not. Fortunately, recent events led to "the straw breaking the camel's back" so I now have the required amount of adrenaline to write this. Have fun.
Disclaimer
This blog is a rant. If you don't like rants, leave now. The blog is not representative of the SAP products that are described in it (yes it is) and you should not take this blog as a recommendation for your strategic decision whether to buy/use this product or not (yes you should). The blog contains slang, foul language, roasting and a little bit of blasphemy. In case you are easily offended by this, be nice and leave now instead of reporting the blog. Thanks!
"What is FI-TV-PL?"
"FI-TV-PL" or "SAP Travel Management - Travel Planning", if you don't like module abbreviations, is or rather was SAP's attempt to supplement their partially well engineered on-premise FI-TV module with Planning Solutions that can be highly integrated into the overall process very organically. Some time later, unfortunately, SAP apparently realized that the processes of external service providers change too fast to cope with. This then led to the statement "FI-TV-PL will be maintained but there will be no further developments in the future". A bit later, SAP announced the great new solution "SAP external Travel Planning"; now doesn't this sound cool and fancy and innovative and whatnot? Here's the deal: It's an application launcher for external online booking engines which then again don't have the slightest integration with SAP at all. It's calling URLs, that's all the fancy new Business Function does. All this and also the recent acquirement of Concur tells us that the major strategy in terms of development for on-premise Travel Planning is the following: "For the love of god, leave us the hell alone and buy Cytric or something".
Well, it could be worse, right? At least FI-TV-PL is still being maintained, right? (pssssst: This is a well woven web of lies)
"What is FI-TV-PL-BIB?"
This submodule of the Travel Planning module is a purported standard API Interface for the "Bahn Internet Booking Engine" (short: BIBE) which is the Booking Interface of the company Deutsche Bahn AG. This API works with a standard Scenario for PI/PO. Here's a rough schematic to show how the technical process works.
This process is a bit odd because it doesn't fully work over the PI scenario. Instead there's a Portal Call for the booking and a subsequent result interface call to poll the booking data from the BIBE into the SAP System, i.e. this is a simple HTTPS connection in the browser.
The second bit of the process is a synchronous SOAP Request via the PI/PO.
"What is FI-TV-PL-HRS?"
This submodule of the Travel Planning module is a purported standard API Interface for the "Hotel Reservation Service" (short: HRS) which is one of the Booking Interfaces of the company Hotel Reservation Service Robert Ragge GmbH. This API also works with a standard Scenario for PI/PO. The technical process flow is identical to steps two and three of the BIBE, i.e. this scenario works purely over the PI/PO.
"Lukas, why are you angry?"
Documentation
Yes I know what you're thinking. "Haha, SAP and documentation, what did you expect?", but I beg to differ: A lot of the SAP documentation has high quality in-depth technical information (for example PA-ESS, CA-MSS-HCM) with practically relevant examples and whatnot; people just fail at searching. Then there's the mainstream documentation which most of the time lacks the "Why" and "How" which leads to most of the ranting concerning documentation and to hiring overpaid airheads with ties; what was their "profession" called again? I forgot. Now, here's the deal with the documentation for the interfaces:
- Implementation Guide: The single steps are documented quite well, if sometimes a bit clumsily maintained. Some of the IMG documentations simply say "refer the field help" and the field help then is surprisingly helpful indeed. Fair enough. The problem however is, that, dependent on the overall process the IMG partially leads to fallacious information and consequences you will only find out about when debugging. I will not point of the details here, since it would kill the "fun".
- Interface Documentation from the Service Market Place (reachable only with an S-Account via service.sap.com/tm-downloads): The Documentation for the BIBE is 10 years old (from 2005), the one for HRS slightly "newer" (from 2008), hence half of the documentation's contents by now are obsolete and fallacious (the other half is pretty good actually).
Well, it could be worse, right? I mean to be safe you can still contact qualified SAP consultants who can disentangle that whole confusion or ask other companies that already implemented these submodules, right? (pssssst: It's much worse than you think it is at the moment).
Acquisition of Knowledge and available sources
This part is going to be very short and vague, because I don't want to skin and salt people openly by name. Let me put it this way: There are a lot of success stories from other companies and consultant companies depicting the successful implementation of these two submodules. Upon contacting these consultants and companies for advice (if need be, against payment) there suddenly was a great silence and the attempt to shuffle out of the situation.
I've created several threads on the SCN forums addressing my questions (and subsequently following problems) and I haven't received a single answer. With that I don't mean I didn't get a feasible solution for my problems, no, I mean nobody ever posted in these threads of mine (that usually never happens).
Well, apparently people don't like us/me and don't want to talk to us/me, fair enough. Could be worse, right? At least there appear to be other customers who use these standard modules so they should amount to something useful, right? (pssssst: Oh, the humanity!)
First attempts of implementation on our side
We started our first implementation efforts in our DEV environment in 2011. What I found out while swimming in the depths of the API and the source code and looking at the interface mappings in the PI/PO was horrifying:
- a few nonsencial service calls here and there leading to random errors in the process flow
- wrong navigation calls in the FPM of the WDAs and missing technical plausibility checks
- tons of wrong and missing functional plausibility checks on ERP side
- tons and tons of wrong cardinalities and wrong data types in the PI/PO message mappings
- customizing tables read for their first entry instead for keys
- incompatibility with non-unicode systems due to hardcoded validation rules in the XML Adapter on ERP side leading to random unicode errors
Now, these are all fundamental technical errors which exclude my own stupidity to maintain the customizing correctly or downtimes and bugs on service provider sides, i.e. this is all very basic functionality which did not work at all. I want to lift out this one very disturbing thesis I've come to belief: These modules have never worked. Best of all, I can actually prove this thesis with technical evidence.
What in the world happened to the most simplistic kinds of Quality Assurance? It seems somebody put them in sacks, drowned them and just released the submodules. Well, here's your Customer Feedback: The product is bad and you should feel bad.
The strategic decision upon passing this information to my project management was: "Lukas, you're somehow going to make it work". Fair enough.
SAP Support via OSS Messages
I'm sure you expect this part to be the peak of the rant. Way off the mark! One colleague from the AGS was always fishing out my messages only hours after I sent them and forwarded them directly to a colleague in the development section who was very friendly, helpful and competent. I was eternally grateful for that fact because the technical subject matter was and is extremely complex because there are a lot of APIs and interfaces talking to each others, some black boxes here and there, lots of packet sniffing needed, etc. I.e. Expensive and nerve-wrecking stuff.
So, Kudos to the SAP Support!
~ Three years later ~
After "finishing the developments" on the two submodules with the dev support so they were actually capable of functioning, things finally started working. It took me another six months to shape the business process to the standard functionality and yet another three to get things working in production (another load of standard errors found in between). So we're now in the middle of 2014, things finally turn out well and everybody is happy.
"Lukas, in the end everything turned out just fine, why are you still angry?"
Let me elaborate on that and let's take a look at the term "Maintenance". Here's what I understand the term "Maintenance" in the fancy SAP universe means: SAP is going to actively maintain the functionality of the respective subject but does not consider new functionalities. Here's what actually happens: SAP doesn't do a goddamn thing until a customer suffers from a generic problem that could have been dealt with years ago.
Here's what recently happened after our systems worked smoothly for a couple of weeks after three freaking years of nerve-wrecking work:
The Deutsche Bahn has recently implemented a new functionality which slightly changes the output from a service consumption (yet it does not interfere with the service description!). As a consequence, yet another blatantly wrong data type in a message mapping in the PI/PO causes the process to crash (it hasn't done so in the past and it hasn't been detected because there were no possible use cases which would have led to a crash), i.e. the service is down in our production. Here's the fun part: This is considered a new functionality! Yes! You know what that means, right? 🙂
The Hotel Reservation Service has recently implemented a new functionality for payment purposes. The consequence is, that we can't pay our bills with the "old" service interface because it doesn't provide the needed parameters! Woo! New Functionality! 🙂
Bottom line: Nothing works, yet again --> fallback to our non-SAP-integrated solutions we already used three years ago.
My recommendations
If you have to make a choice whether to go for FI-TV-PL
I do not know whether there's a likewise cataclysm present within the submodules for Amadeus, Sabre, Galileo, etc. But after my experiences with BIBE and HRS I wouldn't get my hopes up. If you have the luxury to decide whether to go for FI-TV-PL or whether to buy a third party all-in-one solution like cytric (assuming this can't be any worse), for the love of Hasso Plattner, go for the third party solution.
If you're already stuck with FI-TV-PL
Sucks to be you; here are some ideas:
- encapsulate the top of your desk with foam material so it doesn't hurt so much when you bang your head on it
- caramelize your keyboard so it's delicious when you bite it
- try not to remember Dr. Weir from the movie Event Horizon stating "Hell is only a word. Reality is much, much worse"
- retire early
- drink heavily
- convert to Catholicism and tell yourself "I deserve this"
- use a fallback to pen and paper to reduce the TCO by at least 500%
- if you have flying screaming monkeys at your disposal, you could order them to find the reponsible people for this mess and make them pay
If none of the above is feasible, you can still:
I hope this blog prevents some people from experiencing the vale of tears I have marched through. If not, then I hope it was at least fun to read.
Now if you'll excuse me, I have to ready my flying monkeys to do my bidding.
Cheers, Lukas
- SAP Managed Tags:
6 Comments
