AppDynamics goes full-stack deep with SAP Peak

If there’s one word that has come up time and time again across the technology landscape in 2020 (apart from Covid-19 solutions etc.) then it has to be ‘observability’.

This should come as no major surprise.

After all, the cloud model of increasingly containerised and widely componetised computing is essentially abstracted and virtual — so ergo, we need observability to be able to look inside (in-flight) applications.

But we’ve had some of these tools for a while i.e. the notion of Application Performance Management (APM) is not a sub-discipline of cloud, it is (arguably) a fully-fledged adjunct business stream that runs in parallel with the wider development track we are witnessing in cloud.

So then, what’s next in (presumably cloud centric) APM and all-round app observability.

SAP landscapes & environments 

AppDynamics (now a part of Cisco) thinks it could have some of the answer. The firm’s 1 APM solution is this month bolstered by SAP Peak. An AppDynamics product not an SAP one (although no doubt built in close partnership) AppDynamics SAP Peak is a set of monitoring tools that connect the most critical components of SAP landscapes & environments with real-time business context. 

In terms of Enterprise Resource Planning (ERP) penetration, SAP likes to remind us that 77 percent of all worldwide business transactions touch an SAP landscape in some form… so monitoring this stuff is important, no question there.

But (says AppDynamics), “Limitations with SAP has meant that technologists have struggled to identify performance issues across their SAP landscapes and the applications they connect.”

What happens then is no surprise i.e. outages, issues with core transactions and lengthy mean-time-to-resolution (MTTR) — all of which are not good, obviously.

Full-stack observability

AppDynamics SAP Peak monitors real-time SAP logs, metadata, background jobs, S/4HANA database events and the application server. So, it’s a full-stack observability play across SAP and non-SAP components before, during and after migration (to S/4HANA or the cloud).

“AppDynamics SAP Peak is the only solution that gives enterprises a single source of truth of their SAP landscapes with the real-time business context needed to prevent and resolve problems that could have a negative impact on the user experience and in turn, overall business outcomes,” said Vipul Shah, chief product officer, AppDynamics.

Shah explains that SAP Peak builds on AppDynamics’ existing SAP monitoring solution by providing new and advanced functionality, including:

  • Business iQ for Business Scenario Transaction Analytics: Bringing visibility into to how bottlenecks are impacting business processes by allowing users to monitor key SAP business scenarios.
  • ABAP Code-Level Visibility: Provides base-level APM functionality for SAP monitoring that includes transaction/code level visibility, dynamic baselining, easier Root Cause Analysis of issues, reduced MTTR and application flow maps of the SAP ABAP stack.
  • Deep SAP Performance Insights: Supplies dashboards that display performance metrics, logs and events for the overall SAP landscape, including processes outside of the user business transactions. 
  • Server and Network Visibility: Facilitates full-stack visibility across SAP landscapes to identify and isolate infrastructure performance issues.

 

Approved image use – source: AppDynamics

Content Continues Below

Join the conversation

97 comments

Send me notifications when other members comment.

Please create a username to comment.

Restful is easier to integrate and an API very well documented is better than wsdl
Cancel
I need some guidance and cmplete material on RestFul services
Cancel
SOAP
Cancel
REST - lightweight, use this for all communication between Mobile apps and Server.
Cancel
Configuration-related issues abound with SOAP. Is REST easier to debug?
Cancel
What a terrible, terrible article.
Incorrect in so many ways, and doesn't even come close to the stated title of when to use REST or SOAP.

Basically thesedays, the only reasons to use SOAP are if:
- it's the only thing provided by your tools
- it's all you know
- you don't like learning (even easy) things
- you have some fetish for outdated over-engineered tech
Cancel
I would have to disagree with your opinion, it is unsubstantiated and frankly, arsey.
So in an organisation which has a Java Web services heavily consumed, you think you could just replace them all with RESTful APIs. 
If only we could just rewrite everything on demand. I hope you can code very quickly, and perfect code, that will pass the testers first time, cos obviously you are a brilliant genius aren't you...

Cancel
SOAP is more secure than REST but the latter is light and can be easily handled
Cancel
Investigating
Cancel
still learning :)
Cancel
Yes you are
Cancel
till now used SOAP more
Cancel
SOPA is on going process and REST services are need and requirement based.
Cancel
Want to more dig into it.
Cancel
It depends of the work needs to be done. In case of transactional work SOAP web services needs to be used where on other hand REST web services provides simplicity.
Cancel
correction in SOAP: JMS is not a protocol. it is an API. I think it is a typo.
Cancel
this is the best overview i have found. nice job
Cancel
Good one, I must say short & crisp.
It give me a short kind of revision & clarity in concepts after studying so much theory in details about WebServices.
Cancel
Its simple to use
Cancel
Is there any other type of services like these SOAP and REST??
Cancel
I havent used RESTful yet
Cancel
1. Light weight
2. Performance
3. Now as the world is moving from Heavy weight applications to apps and multiple devices support (Smart Phone, Tablet etc). REST opens up lot more client for the exposed WebService than SOAP.
Cancel
1 Light weight
2 Performance
3 Now as the world is moving from Heavy weight applications to apps and multiple devices support that is Smart Phone Tablet etc REST opens up lot more client for the exposed WebService than SOAP
Cancel

1. Light weight
2. Performance
3. Now as the world is moving from Heavy weight applications to apps and multiple devices support, i.e. Smart Phone Tablet etc. REST opens up lot more client for the exposed WebService than SOAP

Cancel
Because the data we are handling is not very complex and we are using the JSON for data transferring. JSON is more efficient than XML as it will be parsed faster than XML(JSON is already in the form of Javascript and all the browsers will understand ).
Ans also some of the browsers have inbuilt support for JSON
Cancel
unfamiliar with REST
Cancel
yes, it is easy to use and also doesn't have any restriction on using xml you can use json,csv and many more.
Cancel
easy to code and Rapid application development, management is also very easy.
security and other related stuff is no big deal.
Cancel
REST is flexible in terms of usage, can be used in mobile apps. fast execution.
Cancel
Rest
Cancel
In a lengthy business transaction, using REST is very difficult and required two much development effort.
Using SOAP, it is easy to develop and manage using the tools available in the market and make monitoring the lengthy process easy
Cancel
Correct
Cancel
I didnt get chance to use rest services. Thats why i want to learn difference between these two.
Cancel
Soap is a standard structured web service.
Cancel
speed
Cancel
learning
Cancel
Because the most of our partners use SOAP. We are a service company in insurance field.
Cancel
While SOAP supports SSL (just like REST) it also supports WS-Security which adds some enterprise security features..
Rest doesn’t have a standard messaging system and expects clients to deal with communication failures by retrying. SOAP has successful/retry logic built in and provides end-to-end reliability even through SOAP intermediaries
Cancel
It is easy to use. Support xml as well as json, lightweight. Also, REST is well documented which makes development easy.
Cancel
It's includes a well-defined self-documenting contract which reduces the need for external documentation and in many cases, depending on the soap server, provides automatic error checking with soap faults.
Cancel
Till now used SOAP and learning about REST.
Cancel
I am ready for some REST!
Cancel
Hiii " i recently used SOAP web services for accessing wcf services from android"
,but nw i'm porting to HTML5,now "how can i access those services"???
Cancel
Mostly working on Complex App, and Web Application only.
Cancel
REST is not reliable because HTTP DELETE can return OK status even if a resource is not deleted .where as SOAP is secured and Reliable
Cancel
Security is not an issue;Protocol is HTTP;Some of the web services were provided;Didn't have to learn a 3rd party WSDL, and the web service client would have to change if the WSDL changes.
Cancel
WSDL saves a lot time while service consumers. REST requires word documents to explain what operations are available what parameters to pass.
Cancel
It sounds like a lot of people are gravitating towards SOAP!
Cancel
soap services
Cancel
Because i am new to web services and for a starter REST is good
Cancel
legacy services were all developed as SOAP/HTTPS. All new services are being developed as REST/HTTPS - many legacy SOAP/HTTPS services are being reimplemented as REST/HTTPS
Cancel
While using REST my application performence is very good compare to SOAP.
Cancel
know less on REST.
Cancel
Hi kamprk,

Here is a link to some recent articles we published on REST. I hope it helps! http://ow.ly/u3Bio 
Cancel
Speed will better than SOAP
Cancel
its simple structure and simple to learn. and it's caching abilities
Cancel
Rest is faster, lightweight and easy to implement.
Cancel
because i don't think SOAP is difficult to learn or use if you're not trying to learn what you may not needed.
Cancel
SOA is a like tortoise, lots of shell and slow to develop.
REST is like a rabbit, bounce around a lot and you have to catch it 1st.
I prefer REST hands-down over SOA.
Cancel
Till production move...management asked us to go for SOAP. But when the test results came out, it was REST who won the battle.
Cancel
Yes,
Mr. ashrafwg say right,
In a lengthy business transaction, using REST is very difficult and required two much development effort.
Using SOAP, it is easy to develop and manage using the tools available in the market and make monitoring the lengthy process easy.

And another thing are
While SOAP supports SSL (just like REST) it also supports WS-Security which adds some enterprise security features.
Rest doesn’t have a standard messaging system and expects clients to deal with communication failures by retrying.
SOAP has successful/retry logic built in and provides end-to-end reliability even through SOAP intermediaries.
so seems all these reasons, I think SOAP is better than REST.
Cancel
Rest is new to me. I'm doing my first REST project now. Seems pretty easy. I may stop using soap all together after this project.
Cancel
Keep us posted on your project, mscrom! It's always nice when a different approach proves to work well.
Cancel
Easy to use
Cancel
Formal contract with external partners.
Cancel
In my experience, consuming SOAP service is extremely providing that you use the right tools. The WSDL is a data contract that allows you to programatically generate the classes you need to access the methods on the service. This means that passing or receiving complex types is simple, a benefit that REST does not enjoy. REST also requires that the service is adequately documented, whereas a WSDL serves as accurate documentation for any SOAP web service. If you are planning on consuming a SOAP service, make sure you use a code generation tool such as SvcUtil.exe (built into Visual Studio when you select "Add Service Reference") in order to make your life easier. Anyone who tells you that code generation tools are proof that SOAP is harder to use than REST is overlooking the fact that in a REST service I have no way of knowing what data the service expects or will return unless the developer has documented it. Try consuming a REST service with no documentation - you can't use a code generation tool because there is no data contract. Now try doing the same with SOAP - no problem, the WSDL is your documentation, so you know exactly how to interact with the service.
Cancel
easy to learn and start development
Cancel
A dedicated adapter is required to consume REST services and less secure than SOAP.
Cancel
Keep it simple. If RESTful web services are designed and documented well, they simply work.
Cancel
Json format
Cancel
It is more easy to use.
Cancel
My applications require more context to be maintained to facilitate collaberation. I would use REST if pushing my apps onto mobile architectures though.
Cancel
Several reasons, main reason easier to maintain. Change the back end anytime, easy to version. No WSDL worries.
Cancel
It sounds like whether REST or SOAP should be used depends on the project at hand.
Cancel
It is light weight, easy to maintain and easily scalable.
Cancel
DON'T HAVE THE CHOICE IN our current SAP version!?
Cancel
Fast & Flexible & Time-efficient development
Cancel
can u please share with me the related topics for both soap and REST .I am a beginner in this PF .
Cancel
Hi Sibaram! We have a lot of articles posted on REST and other integration methods here:  http://ow.ly/wukZt. I hope this helps!
Cancel
Currently i am working on SOAP . The reason is i don't have much knowledge on Restful web services.
Cancel
REST is a still new cup of coffee and need to explore
Cancel
Sundeepelec, I like the way you phrased your experience with REST!
Cancel
Easy to implement
Cancel
Project basis on rest
Cancel
we used earlier SOAP Model... currently migrating to RESTful services
Cancel
Sorry to tell you this, But the definition of web services itself is wrong..
Web services are mainly used for cross platform communication in distributed technologies, because the old distributed technologies like CORBA, RMI uses binary code, so which always uses the same technology across client and server. But whereas web-services uses neutral language called XML, which can be understood by any technology. that’s why web-services provides interoperability, and supports cross platform communications
Cancel
REST - lightweight, use this for all communication between Mobile apps and Server.
Cancel
Architectural decision
Cancel
I recently got to know about REST
Cancel
Pashamshaik, what are your thoughts on working with REST so far?
Cancel
I think Microsoft by now perfecting REST documentation since mobile business holds the future.

Cancel
I am using SOAP WSDL webservice using Axis framework [even though is not being updated from 2012] in my application from the past 5+ years.
Cancel
I've been on the receiving end of both as a tester, and while Soap's defined model may be easier to report, I've long wondered if REST is better, because APIs with better documentation (rather than relying on the discovery service) are actually better in the long run, and more maintainable.
Cancel
Rest is easier than SOAP.REST uses standard HTTP it is much simpler. Creating clients, developing APIs, the documentation is much easier to understand and there aren’t very many things that REST doesn’t do easier than SOAP.
Cancel
Do you more frequently use REST or SOAP Web services?
Cancel
I am sending XML from SOAP UI to web services but web service is removing the tag and accepting only the data between the tags. Any solution?
Cancel
Very nice article Swati Dhingra. Very well appreciated with good explanation.
Cancel

SearchCIO

SearchSecurity

SearchNetworking

SearchDataCenter

SearchDataManagement

Close