cancel
Showing results for 
Search instead for 
Did you mean: 

IAC iView URL points to nowhere after Backend NW AS Stack Upgrade

Lukas_Weigelt
Active Contributor
0 Kudos

Hello folks,

System Info:

NW AS 7.03 ABAP Stack 731 Level 13, ECC 606 (EHP 6) with SAP_HR 604 Level 78 and EA_HR 607 (HR-Renewal 1) Level 29

NW AS 7.02 JAVA Stack 702 Level 16

Background:

We have published a backend transaction as a custom ICF-Service (WebGUI/ITS) and implemented the service in our Portal using an IAC iView. This "construction" has been working for about one and a half year, until now.

Problem:

The IAC iview stopped working when our Backend System (ABAP Basis Stack) was upgraded From SAPKB73111 to SAPKB73113. It neither worked with a NW AS JAVA 7.02 SP12 nor after we completed our upgrade cycle to NW AS JAVA 7.02 SP16 (Portal). The Problem only resides on our DEV landscape so far. On Our QAS landscape where we are still on NW ABAP SAPKB73111 and NW JAVA AS 7.02 SP12 everything is still working. This makes me think it has something to do with the Backend stacks, although that thought seems somehow illogical to me.

The ITS-Gui-Service still works without fail from the Backend via "Test Service" in the ICF-Tree. However from the Preview in the Portal, we get a 404 Error.

What I tried so far / Analysis:

  • We have tried this on several Clients with Several Test Users on Several PCs, with the same result.
  • Clearing all kinds of caches has not helped.
  • Reactivating the ICF-Service didn't help either.
  • I compared the IAC iview from QAS and DEV although it hasn't been touched for a year - they are identical.
  • I only found the following threads that somehow relate to my problem but eventually didn't really help:
  • SAPxSearch didn't return anything helpful either.
  • As far as I see it, I have no chance tracing this with ANST (since the error only can be reproduced from the Portal side).

I did a HTTP-Trace with Fiddler2 and can at least see what's going wrong. The URL on DEV generated by the IAC iView doesn't point to the service anymore but to nowhere (disregard the <censored> bits, I've excluded some confidential information from the URLs):

DEV:

GET //sap/bc/gui/<censored>/its/(ZT1EWmZhRmplSGRER3JtYWpkeTJkZXJBLS1SY29iYkNvOGI3NFZrSEkqKlVfbGRRLS0=)/Web_RPLERDX0?sap-client=101&sap-language=DE&sap-accessibility=&%7EDisconnectOnClose=0&%7EDesignBaseUrl=http%3A%2F%2F<censored>%3A53100%2Firj%2Fportalapps%2Fcom.sap.portal.design.portaldesigndata%2Fthemes%2Fits&%7Edesign=<censored> HTTP/1.1

POST /sap(ZT1EWmZhRmplSGRER3JtYWpkeTJkZXJBLS1SY29iYkNvOGI3NFZrSEklMmElMmFVX2xkUS0t)/bc/gui/<censored>/its/ HTTP/1.1

As you can see the URL points nowhere, i.e. the Service name isn't attached at the end.

QAS:

GET //sap/bc/gui/<censored>/its/(ZT00ZEFMZFdiUV9PM1oqM3Ztc2UyQUNRLS1ndHlvRm5FX0R3UjlpS3E3RHR3T3RBLS0=)/Web_RPLERDX0?sap-client=101&sap-language=DE&sap-accessibility=X&%7EDisconnectOnClose=0&%7EDesignBaseUrl=https%3A%2F%2F<censored>%3A53001%2Firj%2Fportalapps%2Fcom.sap.portal.design.portaldesigndata%2Fthemes%2Fits&%7Edesign=<censored> HTTP/1.1

POST /sap(ZT00ZEFMZFdiUV9PM1olMmEzdm1zZTJBQ1EtLWd0eW9GbkVfRHdSOWlLcTdEdHdPdEEtLQ==)/bc/gui/<censored>/its/Web_RPLERDX0 HTTP/1.1

Here the Service Name Web_RPLERDX0 is contained in the URL and everything works.

I'm kind of stuck here. Any help is highly appreciated.

Cheers, Lukas

P.S. We don't really cling to this solution with the IAC iView, but there's no other way I know of publishing a backend transaction with a customized WebGui (that's why we are not using a Transaction-iView in the first place in case you asked this yourself :-/. If you know a way, I'm also open to migrate the solution to something newer and more elegant.

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Lukas Weigelt wrote:

As you can see the URL points nowhere, i.e. the Service name isn't attached at the end.

Not really following here. The URLs look identical to me, apart from the censored parts which I have no way of knowing what they are. Are you aware that applying Support Packages might deactivate ICF services? Look from the root up all the way down to ITS, all services should be activated.

Lukas_Weigelt
Active Contributor
0 Kudos

Hi Samuli,

the ICF Service is activated. The ICF Service itself does work by the way:

The ITS-Gui-Service still works without fail from the Backend via "Test Service" in the ICF-Tree. However from the Preview in the Portal, we get a 404 Error.

The Urls from the POST Requests are not identical. At the end of the URL in the DEV environment, the Service itself, i.e. Web_RPLERDX0 is missing:

DEV:

POST /sap(ZT1EWmZhRmplSGRER3JtYWpkeT

JkZXJBLS1SY29iYkNvOGI3NFZrSEklMmElMmFVX2xkUS0t)

/bc/gui/<censored>/its/ HTTP/1.1

QAS:

POST /sap(ZT00ZEFMZFdiUV9PM1olMmEzdm1

zZTJBQ1EtLWd0eW9GbkVfRHdSOWlLcTdEdHdP

dEEtLQ==)/bc/gui/<censored>/its/Web_RPLERDX0 HTTP/1.1


Cheers, Lukas


EDIT: Gnah, now I see why it looks identical to you. I've included some line breaks so the HTML content doesn't become scrollable -_-


Message was edited by: Lukas Weigelt

Former Member
0 Kudos

Lukas Weigelt wrote:

EDIT: Gnah, now I see why it looks identical to you. I've included some line breaks so the HTML content doesn't become scrollable -_-

Now I see how the URLs are different, I was just looking at the GETs. I guess the problem originates from having a non-standard path to ITS. Is the IAC alternate path iView property set correctly? See SAP note 1713241 for details.

Lukas_Weigelt
Active Contributor
0 Kudos

The alternate path is set in the iView:

Former Member
0 Kudos

Place an external break point in method IF_HTTP_EXTENSION~HANDLE_REQUEST of class CL_HTTP_EXT_ITS:


  call method server->set_session_stateful_via_url

    exporting

      stateful   = if_http_server=>co_enabled

    changing

      rewrite_url = path.         " <-- external break point

What is the value of path? The method gets called twice, first for the GET and the second time for the POST. When called the first time the method builds an HTML response page containing a form that will be automatically posted which results into the POST.

Lukas_Weigelt
Active Contributor
0 Kudos

I debugged as you suggested (Initiated from the Portal). The value of the path is:

/sap(ZT1wM0RXWEU0Q3dUb3JUTlFBOUhxJTJhM

VEtLUI2ZEV4bmdnXzY1JTJhSDViWnZuck1ZQS0t)

/bc/gui/<censored>/its/

As far as I can tell, though, the method was only executed once (I assume so because the Breakpoint didn't halt again when I pressed F8).

I tried to debug the whole thing again via SICF + "Test Service" for means of a comparison but the break point didn't halt (neither external for my logged on user nor with a session breakpoint). I assume that's because CL_HTTP_EXT_ITS is only used for external calls (assumption because of the EXT in the class name), is my assumption correct or should it have been possible to debug the bit of coding via SICF + Test Service?

Does the variable "path" normally also include the Service Name? I.e. should Web_RPLERDX0 be at the end of the path? I'm asking because I debugged through the rest of the method and the preceding callstack but didn't find any dedicated "append Service Name"-portion or the like.

Cheers, Lukas

Former Member
0 Kudos

Yes, the service name should be part of the path. I think there is a bug in the URL parsing for non-standard ITS paths.

Lukas_Weigelt
Active Contributor
0 Kudos

Our Upgrade Cycle reaches our QAS System this evening, so tomorrow I'll know if this error originates from the Stacks SAPKB73112 + SAPKB73113 and I'll have enough Info for opening a Support Message.

I'll keep you updated.

Cheers, Lukas

Lukas_Weigelt
Active Contributor
0 Kudos

'Aight, our Upgrade Cycle has passed our QAS System and the error can now be reproduced here as well, so it's indeed most likely a standard issue shipped with SAPKB731 ST12+13. I'll open a Support Message.

Lukas_Weigelt
Active Contributor
0 Kudos

The problem could be solved with help of the SAP Dev Support. The root cause couldn't be found ultimately, but here's what we did to solve the problem (configuration):

In the alternate Path of the IAC iView, the the leading and the trailing slashes have been removed, i.e. from "/sap/bc/gui/<censored>/its/" to "sap/bc/gui/<censored>/its". Additionally the parameter itsp/sessionid_path_position in TA SITSPMON has been set from "1" to "6".

I don't understand in-depth why this problem occured in the first place, i.e. which updated component in the backend suddenly decided not to like our parametrization anymore, thus I don't understand either, technically, how the problem has been solved, but...oh well!

SAP = Magic

/Thread

Cheers, Lukas

Former Member
0 Kudos

The changes done affect the URL parsing and I think it's only a workaround. I wouldn't be surprised to see a SAP note released in the near future addressing the real issue which is that they broke the parsing.

Lukas_Weigelt
Active Contributor
0 Kudos

That's... reassuring? I guess?

Answers (0)