Weird issue with Stored Process Portlets in Information Delivery Studio

[nflynn]

I thought I'd try here because maybe someone else would have had this issue previously and know how to resolve. SAS support hasn't been much help so now i'm resorting to other methods to get this sorted. 

We have an issue when trying to add a store process portlet to a page in formation delivery studio. Here's a screen shot below. 



As you can see, it's an IIS error. The STP portlet successfully adds to the page, but when we try to link in any stored process, we get this error. The odd thing, is that any old stored processes portlets that were linked before this issue still work. The error shows 500.19 but when we use the relative path the error becomes 404.18 which basically says that IIS cannot find what it's looking for.

What would have changed in SAS that could have caused this issue? Nothing has changed on the IIS side

Thoughts/comments/suggestions welcomed.

[boemskats]

First off, your error: it looks to me like IIS can't find the 404 page you've configured it to show in the system.webServer/httpErrors section of your IIS config, which is why IIS throws that 500 error. So what you're dealing with is just a 404 error and some IIS misconfig. I assume something has changed in IIS if you were getting standard 404 errors before, and I'd be interested to know what you mean when you say 'when you use the relative path', as opposed to not using it. 

It's been a long time since I've had to use the IDP or IIS or Windows, but you asked for thoughts/comments/suggestions, so here you go. The first thing I would do is 'view the source' of that portal page that you attached the screenshot of, in order to pull out the address that that iframe with the error in is pointing at / trying to load. That would most likely give me an idea of where it's all going wrong. I'd then try to debug access to that URL outside the portal.

Do you have any kind of load balancing config with IIS? Have you recently switched desktop locales? 

[nflynn]

That's the reponse error that was given to me from IIS. I didn't write that "use the relative path" portion. We're weren't getting errors from the portlets at all. When I modify IIS to use the absolute path, it gives me a 404.18 (see attached).

this describes the difference between absolute and relative paths

http://www.coffeecup.com/help/articles/absolute-vs-relative-pathslinks/

'https://bsr.aba.com:443/SASBIPortlets/ViewerStoredProcessAction.do?sas.portlet.container.client.id=d...

^that is the URL that is causing issues. I'm not quite sure how to debug access to a URL. 

We don't not have any load balancing in IIS that I am aware of (the server farms section is blank). Nothing else has changed that I can tell. Haven't switched desktop locales. 

[boemskats]

Ok cool - what happens when you try to access that SASBIPortlets URL that you posted, but directly through your browser? Log on to a fresh session in the portal, go 'view source' again, pick out that URL (complete with the sas.portlet.container.client.id bits), paste it into another browser tab - do you get a 404, 500 or a message saying 'An error has occurred. Please contact the Administrator'?

If you go into SAS Management Console as an admin, go to Plugins -> Application Management (bottom bit) -> Configuration Manager -> SAS Application Infrastructure -> BI Portlets, right click that, Properties, Internal Connection, what host name / port / service do you see? What about the next tab, External Connection? 

Is your Portal application also running as HTTPS, on the same port, 443? Do you access it using the url of https://bsr.aba.com:443/SASPortal/ ?

I'm guessing you've been through all of this with the support team...

[nflynn]

When I post the link to that portlet in a new web browser, it just brings up the same error you see in the last screen shot - 404.18

There is only one connection tab. Communication Protocol is HTTPS, Host Name is bsr.aba.com, port number is 443, and the service is /SASBIPortlets

Yes. Portal application is also running as HTTPS over 443. The weblink you've listed is correct and takes me to the correct log in screen.

Yeah it's gotten to the point where support is barely even responding to any of our emails. They don't know what's going on and neither do we 😞

[boemskats]

Might be an obvious question, but have you tried restarting your JVMs? Do you have access to the mid-tier logs?

I honestly don't think it's a complex problem, you should be able to trace it quite easily. Try restarting your mid-tier, and if everything else works but this still doesn't, locate your jvm logs and post them up here. What version of SAS are you running?

[nflynn]

I have access to everything. I rebooted the middle or what they call 'web' tier in our SAS 9.3 environment. The issue is still occurring.

I'm having a hard time locating the JVM logs. I'm running Windows Server 2008 R2. Where should I be looking? 

[nflynn]

I've found the JVM directory, I do not see any logs

[nflynn]

So I think I figured it out 🙂

There seems to be a redirect going on that's making bsr.aba.com/SasStoredProcess redirect to bsr.aba.com/sasportal

[boemskats · Accepted solution]

Ok, so I think that the two places to check for that would be:

a) In SAS management console, as previously, under the Application Management / Configuration Manager bit but this time for either Poral or your STP webapp

b) Your URL rewrite / reverse proxy rules that you probably have configured in IIS to manage the incoming connections

That's great if you've found the solution to your problem, but it's strange that the previously deployed portlets still work, whereas the newly deployed ones don't. 

FYI the JVM logs in SAS 9.3 will depend on what middle tier server you're running. With JBoss it's probably a file called server.log, under the SASServer1/Logs directory (or something like that, it's been a while). It'll be the biggest, most recently written logfile, and if your error is SAS-side, you should get a lot of information by looking at what information is logged there as you're trying to access these applications directly via the URL.

Anyway, hope it's sorted.

[nflynn]

I accepted the above as a solution because this was more helpful than some of the support I got from the technical folks at SAS. We took this discussion off of this board because I didn't want much being public

But SAS support seems to be unable to interface between teams, and eventually just stopped responding to our emails all together. Really disappointed with the support. Eventually we opened up a case with another team, once that particular team stopped responding to our emails and suggestions. We got a workaround, but not solution to the problem.

Thank you for your help, Nik! With your help I am now better equiped to not only understand the problem, but resolve it as well. Cheers!