I wrote my first The unfortunate cookie on SDN exactly a year ago. It covered the problem of the session id changing during the session when the browser is set to not allow cookies. Strangely enough that same problem cropped up again a year later. The problem this time was caused by Stack 14 of the WebAS. For the sake of clarity, and to prevent you from leaping to conclusions, here is a short overview of what happened.
Portal
We discovered this problem when we were doing some testing before doing a demo for the users. When I tested it there was nothing wrong with the application, but when my colleagues tested it their data was lost when they moved from one page to another. That was rather strange. At first I thought that it was a problem of browser compatibility. I usually use Firefox and my colleagues use standard MIE. Maybe there was something wrong within the application, which was masked by a cloak of charity by the new version of Firefox. A quick test with MIE on my machine told me that this was not the case. Everything worked fine. Was it my PC? All PCs in our department, except mine – for testing purposes, are managed by Tivoli . Maybe there weren't enough access rights anymore on the Tivoli PCs? I couldn't see any connection though between that and the application. Unless, of course, it couldn't access the cookies, and had the same problem as described in the above mentioned web log. We needed to debug the application in order to determine whether that was the problem. And indeed the session id remained the same on my PC but not on my colleagues' computers. It wasn't the PC that was the trouble maker - it was our portal. My colleagues used the application from within the portal but I didn't. I never do, certainly not in the development stage. The next obvious question was why the portal made a difference. I don't know if you've noticed it already, but the URLs of the BSP are longer when called from EP than from outside the portal. The URL mangle is much larger, with as side effect that the mangle was different each time the BSP started, which was rather tedious for static info (like MIMEs). Since the URL was different, the browser concluded that the content was different and wanted to retrieve the static data from the server with all latencies and extra traffic as a result. This problem was solved with note 857476. Could it be that the URL mangle was causing a problem for the cookies too? Turning on the portal integration in the application properties didn't change this behaviour.
Stateful or not
I'm going to keep you in suspense for a bit though and tell you about an interesting discussion we had about cookies. First of all, the use of them, and how to choose between stateless and stateful applications. I'm from the old school of web developers and started web developing in a completely stateless web world. My philosophy is to only turn to stateful when it is absolutely necessary, meaning when one needs to keep a large amount of data in the back end without actually saving it. A shopping basket is the perfect example of this. But that comes with a price as I stated in my ‘State of the enemy' Enemy of the state . This is why I prefer working with cookies in a stateless environment when only a small amount of data needs to be kept and exchanged between pages.
Secondly comes the discussion of the use of the session id when creating cookies. According to this help page , it needs to be set to runtime->session_id, but this help page indicates that it needs to be static. If it can be static, what's the use of it? Brian states in this forum Where can I find the session ID that the runtime->session_id is only of interest if you are running stateful. But when do you need cookies in a stateful application?
Anyway, I was a bit afraid that for some reason the philosophy of cookies had changed somehow without our knowledge and that we needed to change all our session ids in our (stateless) applications to a static string. Or worse, that due to this all our applications in the production environment would fail. Luckily for us the latter was not the case. But how could this be?
The stack man
The difference between our production, quality and development machine was the stack that was installed on these environments. Our development machines had already installed for further deployment during the holidays at the end of last year. It was clear to us that further deployment was impossible and, depending on the reason why this behaviour occurred, we would need to either alter all our code or have a fix for this problem. So the obvious next step was to open an OSS message. Despite the upcoming holiday season we got an answer very quickly:
“The problem is a consequence of changes described in the note 764951. This change resulted in suppression of sap-appcontext, which contains session id in decoded form. It remained latent because of rare usage of sap-syscmd=nocookie parameter. Lately, the problem was exposed by the portal policy to start BSP applications with this parameter”
This can be found together with the fix in note 909353: “Session id doesn't remain stable in stateless application“.
Implementation of this note did indeed fix our problem and we were able to continue implementing stack 14 on all our environments.
OSS and SDN save your day
As you can see, it's worth the effort of opening OSS messages when you have a problem which doesn't seem to be solved or elaborated on in notes and SDN. It is also important to share the solution provided in order to prevent people from losing time by reinventing the wheel. SDN is the best place to do so.
