BookmarkSubscribeRSS Feed
sriram
Obsidian | Level 7

Hi ,i am facing an error with SAS Reports in my Portal . Where to find the Logs about the Report error . Either to look in content server logs or to check with the Compute Tier logs.

Also ,SAS reports in my Portal works fine with the Logins , but at times it throws an error stating "operation failed and cannot open the report". What can be the root cause of such error , beacuse other reports inside the same portlet works fine.

FYI , in this case reports are fetching data from infomaps, and no changes are being made over the infomaps.

Could you please help with these. Appreciate your response.

Thanks,

Shriram

5 REPLIES 5
jakarman
Barite | Level 11

Each log is describing the functionality of each involved component. Checking logs is also requiring knowing what each component is doing.

- When you have the suspect the processing/data of the sas-code is causing something check the compute tiers appserver parts,

- When you have the suspect the sas-metadata server is causing something check the metadata-server loggings

  Sometimes more information eg of the computeserver is stored as feedback. 

-  When you have the suspect of the portal/webappserver not working correctly try to find something there.

Root cause analyses start with getting a picture of the issue.

- is it stable replayble or intermittent, When intermittent how often.

- was there some change related tot that.

- when possible with several scenarios is there some relationship getting out of that (different browsers/users/locations)

- what are the issues and is that possible related to some used technique

Eliminating possible causes can help to get more close to the real cause.

What you have:

- it is about one report.

- your are using infomaps (looks to be an exception) it is not changed.

  Either it is intermittent or it is about some special conditions. Did you try it with exactly the same input.

  Infomaps are views to underlaying data. The metadata plays a central role. The underlaying data is important. Anything on that?

---->-- ja karman --<-----
Shriram
Calcite | Level 5

Hi Jaap,

Thanks for the Response.

Moving with the Root cause analysis:

It is a report which is fetchable at soemtimes and at other times it doesnt work properly. I am trying to fetch the report with the same user login, there is no recordings of logs over this error.

The report is fetching the data from infomaps , these infomaps have been made static from long, so the error doesnt seem to be from the data fetch.

Expecting the report is not reaching the portal or causing an error while fetching from the portal.

Please share your thoughts on this.

jakarman
Barite | Level 11

You are trying with the same login the same report. It looks to be an intermetittent problem.  You did try this from the same location (office/laptop).

- trying to eliminate router network issues between your broser and the web-environment.

- web-pages are cashed locally (your browser) but sometimes locally cashed wrong. Did you try to eliminate this possibility?

The infomaps are just a view to real-data. When the infomaps are having external DBMS tables connected you could be suffering on connection and performance issues on that part. Do you have external DBMS-system?  Just another possible cause to eliminated.  The infomaps can be static but the data the infomaps is using need not.   

The  more is eliminated you are getting to your webservice metadata and computetier.

It would be marvelous APM is running as that would show you who what when is happening (essential activating more logging).  

---->-- ja karman --<-----
Shriram
Calcite | Level 5

Hi Jaap,

You are absolutely right. This seems to be an intermetittent problem. I am trying it from office.

Lets go with the first case. Assuming it to be a network issue, what can be the other changes be made apart from deleting the cookies and trying the portal from a new browser. In my case this seems to be working this way . The report is unaccessible from one browser , at the same time works fine when tried opening with other.

Could you please elaborate about the web pages cashed , i am not aware of that possibility.

Secondly , Infomaps feches data from Oracle database. Please also let me know about the on connection issue or the performance issue you have quoted.

Trying to eliminate all the possibilities to avaoid the cause of this issue.

Thanks in Advance.


jakarman
Barite | Level 11

As you are saying you are trying with one browser (not working) and other same machine? (working).  That is strange.

The browser history is the one that is having the cache. The last page can be in memory. Deleting that history and restarting the browser is a test. In the header of a html file is a revisit-after entry. This instruction tells the browser when it needs to go to the browser and when allowing chaching.

If you are experiencing location specific behavior (either VDI or physical) this ones are my experiences.

- domain segregation in network blocking some access

- Firewalls/routers implementing a session time out (2-hrs)

- Some routers correcting wrong defined OS network connections.

- spurious lost traffic in network connections to some locations while others kept working (never found the cause).

The oracle connection was an other strange part. It was overloaded at some moments in the week. That is why it was found.

It stopped working new incoming sessions going in a never response mode. Some were still working (started in time) others got blocked.

The response in Oracle was terrible founding it was updated one a month a copy to a SAS datasets did wonders. in 10% of the original time the program ran unmodified. The design of that program was far from logical because of that bad Oracle behavior.

This only can be verificated with your Oracle DBA. Can be problematic as Oracle is a holy tool for them. The best approach will be asking for monitoring what is happening at that side when you are for sure you can hit the problem. Session at that side should not hang and respond quickly.             

---->-- ja karman --<-----

suga badge.PNGThe SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment. 

Join SUGA 

CLI in SAS Viya

Learn how to install the SAS Viya CLI and a few commands you may find useful in this video by SAS’ Darrell Barton.

Find more tutorials on the SAS Users YouTube channel.

Discussion stats
  • 5 replies
  • 1753 views
  • 0 likes
  • 3 in conversation