Business Transaction Management Demo: Nastel AutoPilot® in Capital Markets

Hello, welcome to the demo for nastel technologies autopilot. My name is Charlie Rich. Nastel is the leader in application performance management across distributed and mainframe tiers for over 15 years. Why? Well because we provide 3 important things. Visibility, prediction, and performance real time 360 degrees situational awareness of your applications middleware and your transactions. Why is that important? Because this can help you reduce risk by providing transparency and maximize the service you can deliver to your customers. Prediction instantly knows when your apps and transactions are beginning to veer from that state we call business normal to business abnormal. Take action before it hurts. and finally performance, ensure peak performance and availability for your business applications and transactions and do it at a lower cost and with less impact to your staff and customers. How do we do it? The difference is business transaction performance. At the core you can see we have our own complex event-processing engine, this is taking in data from probes that discover transactions. These can be nastels or third parties application performance management data both operational and transactional. Deep dive middleware management, things like web sphere mq, tibco, etc. and your own business activities. The complex event-processing engine can rapidly search for patterns that show availability and performance and trends such as veering towards business abnormal as we spoke about before. and putting this all together gives you that visibility, prediction and performance we spoke about. Now under visibility notice I mentioned transactional and operational. What do I mean by that? Transactional is a discovery of what happened. Were capturing this transaction, started on the web server, evokes something on the apps server called middleware messaging, went to the mainframe, the database, etc. That lets you get a pretty good understanding of what occurred. Operational is why your getting the resource consumption for the servers, the network, applications, etc. Putting these two together gives you what and why that lets you close the loop, not only understand the state of what's occurred, but understand the underlying or what's called the root cause and by having that information you can remediate and rapidly restore service. This is across both distributed and mainframe. And predicting as we mentioned before very powerful think of this as governance a way of implementing your policies measuring those against SLA's and preventing disruption to business processes, and then finally performance improving the performance of your transactions be they trades, payments, claims, order processing, etc. So how do we do this, well let's take a look at this were going to build this in layers. We'll start with normal systems management servers on a network. Now we have our own agents or instrumentation, but most folks already have that already and were very happy to use that from your enterprise management software. This could be hp operations center, ibm event monitoring, ca's instrumentation, bmc's, and many different sources that operational data is fed up to our complex event processing engine for analysis. Then we add the important middleware-messaging layer. This is where applications like payment equities, funds transfer, claims, etc. This is where they communicate; if you don't have deep visibility here you are missing a lot of what's going on. So that middleware messaging is also fed up to that complex even processing engine and correlated with the operational data. Now we add our transactions highly volatile and you can see we keep track of their movement their state. Here's a lost one, we have another here that fails and we automatically capture all of this information and even their interdependencies. This is called stitching, so trade entry is stitched to validation, which is stitched to auditing customer information and tracking this transactional data and your business kpi's are all fed into the cep engine complex even processing engine and all of this together is what nastel means when we call this 360 degree situational awareness. So lets look at a real life customer scenario in financial services middle office. So this is right after the trade is made, this is called validation and enrichment. So validating that the information in the trade is correct and adding additional information about the user we have running websphere, were running message broker and the process is trade entry validation auditing customer information and tracking. So what's the problem here? Well the customer scenario here is this exactly what happened after the trade. We seem to have a disagreement it says its done but the customer says I haven't heard anything. What happen to my order? and that's order 1234 a whole lot of zeroes and one so the business has a problem and that they don't have the visibility they need. So what do they do to remediate it? They did what a lot of firms do, we jokingly refer to this as the blame game. They brought everybody into a room, locked the door, had a session that went on for 8 hours. This included the network folks, the web servers folks, app server people, database development, just about everyone and everyone said it's not our problem. You know they particularly had a silo approach as many firms do. This thing eventually somebody would wear out and end up wit the responsibility to resolve the problem, but this is no way as they say to run a railroad. Its just to expensive, too costly, and the results were the opposite of what they expected. Service to customers actually went down. So they brought in autopilot for its visibility and situational awareness and began to remove the blame game. So digging in a little deep here, so we see it said that validation and enrichment transactions are regularly exceeding their sla's. Ok but we don't have any visibility as to which it transactions are associated with. A business trade ID, we see java, we see jdbc, we see messages, we don't know what trade that is. So how do we resolve this? Looking a little further we find out that the trade id is stored in the packet inside the middleware message. So they needed improvement in visibility in order to do this deep visibility so that they can deliver a complete understanding of what happened. Not only from the IT prospective, but from the customers prospective of the trade and have both of those be completely in sync. So lets look at our message payload, we see here our middleware messaging and these message packets have the trade id as I said embedded in them. Autopilot goes out extracts the trade id from the middleware packets and we'll look at the xml here and we see the trade id is 1234 a whole lot of zeroes and one. Autopilot will take that information feed it to its complex event processing engine, which is very busy here and will use this to stitch together the transactions or understanding of the trade id. Alright lets go look at this in action. Here autopilot is set up and will automatically discover your transaction topology and the applications that evoke them. So first off here we have our websphere application server ,here weve discovered websphere mq, the mainframe running z/os and cics's running on top of z/os. Automatically autopilot will discover that the trade audit application has caused the SLA to be breached. Let's go into details see how that worked and by the way notice were also keeping track of operational data here and that were completely ??. So you could see a rolling real time graph showing a ?? for trade audit. So if we look at this we can go in and do a search for trade 1234 a whole lot of zeroes and 1 lets do that well search well see its state. Lets drill into the details to understand why this has happened. Why did it miss its SLA? Wel'l start off first with its http request and then follow its interdependencies. So here we have our http post trade entry. What happens next? Looks like we have a jms call queue sender send, this goes off to message broker and that's going to be automatically stitched to the http request and then we have after the jms call stitched to that is a websphere mq MGET as you can see, but look at this its elapsed time was 4 seconds. This is where the SLA breach occurred and if we continue on we see that after passing through websphere mq the application initiated a transaction in cics on the mainframe and you could see the start BR customer info. Lets do the return trip and we went back from the transaction went from cics to message broker. Then the next step its going to go back using and mq mput this is through jms back to the application server websphere application server. So lets take an understanding of this bottleneck we saw that led to the SLA violation or breach on trade audit well go back to that real time rolling graph we saw here and were looking for validation and enrichment governance. So this is an effect the status of our trade audit policy and you could see were completely ??. Here were in the state we referred to earlier as business abnormal, were looking at the trade audit impact queue and thus we have our root cause trade id 1234 a whole lot of zeroes and 1 was caught up in a failure in order processing due to a bottleneck on trade audit input queue. So why nastel? well we've been labeled by Gartner in their magic quadrant on application performance management as a visionary. We were praised for deep expertise in wmq and java enterprise edition ?? technical sophistication code excellence. We support all five dimensions of the Gartner model. 15 years of deep middleware messaging expertise. Why is that important? Because the visibility that gives you we believe is the key to unlocking business transaction performance visibility. 360 degrees situational awareness both operational and transactional, what happened and why it happened correlated together in a business context across both distributed and mainframe tiers. Doing it predicatively, remember act not react find those problems and resolve them before they hurt. and performance uncover the bottlenecks to maximize performance. and we have a successful track record of delivering all of the above. So if this was helpful or interesting to you please feel free to contact me crich@nastel.com or visit us at our website www.nastel.com. You could find us on twitter or linkedin and wed be glad to offer you an assessment and show you how nastel autopilot can help your environment reduce your costs improve service and manage risk. If your interested please feel free to contact me to arrange this and thank you for watching.

*First Name

*Last Name

*Company

*Email

*Phone

Click here to view the demo