Skip to Content

Do you really need Buy-in from the top?

Primary audiences of Wily Introscope tool are SAP Infrastructure teams.  Buy-in from top management is possible if Basis can produce value using Wily. I would like to recommend this tool as common tool among Basis team members and should never be tagged as an exclusive tool of an expert team member or consultant.  No one really cares whether Basis uses Wily or not, because you are obligated to address sap system performance & regular exceptions being a Basis administrator. So you may think “why should i use”? Well, it’s all about 21st century style of monitoring SAP systems! Buy-in from Basis team members is important. SAP delivers a limited version called RTV Wily. (Right-To-View is nothing but a limited version of full Wily). So to find out whether Wily can generate value, Basis teams must use this tool in their daily job to get more visibility of their SAP systems. Once monitoring analysis from Wily is included in Basis decision making, your colleagues & management indirectly depend on Wily data. It can also lead to a time when the limitations of RTV version are hit and customer look for licensed version of wily.  Buy-in from management is needed only when you want to buy the product. In this case just use the RTV version and truly use it to empower yourself.


Significance of having 2nd monitor

Wily is a tool that has numerous types of dashboards which can display real-time sap performance and historical data. A second monitor screen/display is recommended to realize its potential. Here are few benefits:


  • By having Wily real time graph running all the time, you will have visibility of peak times and how the sap system is behaving at different times.
  • Email checking, SAP GUI work and Wily monitoring can be segregated having dual monitors.
  • In fact the more the no.of monitors it’s more comfortable for Basis analyst. For example, you may have to monitor memory utilization of 2 SAP Production systems each having 4 application servers. So it becomes very clumsy and confusing to identify which line graph belongs to what sap system.
  • Having wily running on additional monitor can get your team members too interested.
  • Wily graphs on 2nd monitor can become sales pitch if you are trying to get the approval for its license.


Navigating Wily Workstation Console

Wily workstation console navigation is intuitive. Some of the obvious features you need to know are: Lens, different types of dashboards, metric documentation, and zoom in, viewing historical data.

/wp-content/uploads/2014/04/fig1_425419.png  

Figure 1

Lens button is shown above in Fig.1. Wily Enterprise Manager identifies each SAP system host by SMD Agent name only. Use the lens option and Filter option before jumping into analyzing dashboard graphs.


/wp-content/uploads/2014/04/fig2_425420.png  

Figure 2

Fig. 2 above shows different SAP system dashboards.  SAP ECC systems can be monitored from ABAP type dashboard. BI Java systems can be monitored from Portal and J2EE dashboard. J2EE dashboard can be used to monitor any SAP system whose Netweaver stack is of type J2EE.  Host level metric monitoring like CPU, memory, and swap space, disk & network performance is done from Host dashboard. BOBJ web servers are monitored from Apache Tomcat dashboard. Process Integration has an exclusive dashboard PI. Notice the page numbers above the dashboards. Wily can also dashboards for SAP partner products like Redwood, Vertex O series…etc.  Refer to note#1579474 for enabling partner dashboards.

/wp-content/uploads/2014/04/fig3_425421.png  

Figure 3

Clicking the “i” inside the circle as shown in Fig.3 opens up documentation of that particular metric. In this case the metric name is “Free Dialog Work Processes” and below is documentation displayed.


/wp-content/uploads/2014/04/fig4_425422.png  

Figure 4

Knowing metric definition is an important prerequisite before navigation of Wily dashboards. Most of these metrics come pre-defined by SAP Wily. No customization is possible on RTV version. So in-order to analyze the metric graphs on Wily dashboard understanding metric definition is prerequisite. If you do not know what you are looking at, it pretty much generates no value.


/wp-content/uploads/2014/04/fig5_425423.png  

Figure 5

Fig.5 shows a sample 30 day trend of “Free Dialog Work processes”. Notice the circled areas indicating free dialog work processes coming down to level zero. Zooming into those densely populated data points can reveal finer details as to which sap application server this is happening on …etc.

/wp-content/uploads/2014/04/fig6_425424.png 

Figure 6

Notice the small rectangle in Fig.6 dashboard. That is the zoom selection area. It can lead to finer details about the metric.

/wp-content/uploads/2014/04/fig7_425425.png

Figure 7

Fig.7 is a zoomed version of same graph explained earlier. By using zoom feature it will reveal about how many times sap system has ran out of free work processes and how close it was.

How to generate value from Wily Dashboards?

In Basis world value only gets generated only when a problem is fixed proactively or reactively.  Another way to extract value from Wily is to take wily information as input factor for sap sizing projects/capacity planning.

So do we wait for the problem to happen or create a problem? Let’s take the no side effect path.  Make a practice of analyzing wily graph data at least twice a weak. Here are few examples how I was able to spot problems from Wily dashboards

Case 1


SAP System type

BW Production systems

No.of Application Servers

4 application servers including primary application server

Database

MSSQL Server

Operating System

Windows server

I was going over wily dashboards to see if I can spot any bottlenecks in memory, CPU, free work processes. I usually look past 30 day trend with 1 minute time resolution.  It does bring a dense graph which may be difficult to understand at first. I would say high watermarks/peak values can be spotted from this graph type. Below is an example:


/wp-content/uploads/2014/04/fig8_425426.png  

Figure 8

In above graph, notice the circled data points. It reveals a fact that a particular BW application server was running out of swap space. While the there is no such problem occurring on other application servers. So it made me curious as to why only this app server was facing the problem with swap space? I remote logged into that corresponding Windows server and checked the swap space and learned that swap space is set to “System Managed” unlike other servers where it was set to 30GB explicitly. And immediately I informed Basis team and planned for scheduled down time to change swap space setting. We submitted the proof for the same during CAB meetings and let everyone know that Wily was behind this. J

Case 2


SAP System type

SAP ECC Production system

No.of Application Servers

4 application servers including primary application server

Database

MSSQL Server

Operating System

Windows server

Here is a different situation where 100% of spool work process utilization is spotted. This is alarming trend as you can see the system was running out of spool resources very often in past 30 days. And also in addition it’s happening mostly on application server 4 and few times on app 3.  So shared the finding within the team and took a decision to add 2 more spool work process on respective application servers.


/wp-content/uploads/2014/04/fig9_425427.png 

Figure 9

Take a proof of graph picture to CAB meeting before asking for change approval. So everyone knows how Wily graphs can bring value.

Case 3


SAP System type

SAP CPS Redwood

No.of Application Servers

2 J2EE application servers with single server node

Database

MSSQL Server

Operating System

Windows server

In this case we were in the stage of going-live with migrating SAP jobs to SAP CPS Redwood. SAP Redwood is a java application that runs on SAP J2EE server. As you see 2 circled areas in Feg.10, the first one highlight a spike in j2ee server node memory. It bumped up to 4GB from 2GB and was almost about to max out. Immediately the max memory was increased to 8 GB from our end.

/wp-content/uploads/2014/04/fig10_425428.png 

Figure 10                                                                                                 J2EE app server1

/wp-content/uploads/2014/04/fig11_425429.png  

Figure 11                                                                                                 J2EE app server 2

Another interesting trend observed from above figures is that memory consumption on first application server was gradually increasing and on second application server it was kind of steady. This is something we decided to ask SAP for clarification. Our assumption is that whatever jobs we defined by logging onto first application server were sticking to same server and never use load balancing. It may because CPS doesn’t receive requests from end users; rather it schedules jobs on connected sap systems. SAP recommends only one server node per application server. So far from this case they are 2 major observations happened. One observation lead to memory increase from 4 to 8GB .Second one is still in investigation stage as to why memory consumption is gradually increasing only on first application server and not on second application server?

There were numerous instances where Wily helped us proactively detect problems. Also it is not just about fixing problems, it’s a new way of monitoring your SAP system

 

CONCLUSION

No doubt that even a limited Wily version can bring substantial value. Understanding of sap system architecture, workflow and corresponding metric definition is key to understand the wily graphs.

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

Leave a Reply