(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2009/0006614 A1
`(43) Pub. Date:
`Jan. 1, 2009
`Le et al.
`
`US 20090006614A1
`
`(54) MONITORING WEB SERVICE
`TRANSACTIONS
`
`(75) Inventors:
`
`Bach Le, San Diego, CA (US); Tim
`Drees, San Diego, CA (US); Lenny
`Ratchitsky, San Diego, CA (US);
`Peter KirWan, San Diego, CA
`(US); Rares Saftoiu, San Diego,
`CA (Us)
`
`Correspondence Address:
`PROCOPIO, CORY, HARGREAVES & SAV
`ITCH LLP
`530 B STREET, SUITE 2100
`SAN DIEGO, CA 92101 (US)
`
`(73) Assignee:
`
`(21) Appl. No.:
`
`NEUSTAR, INC., Sterling, VA
`(Us)
`12/163,659
`
`(22) Filed:
`
`Jun. 27, 2008
`
`10\
`
`Related US. Application Data
`(60) Provisional application No. 60/946,931, ?led on Jun.
`28, 2007.
`Publication Classi?cation
`
`(51) Int. Cl.
`(2006.01)
`G06F 15/173
`(52) us. c1. ...................................................... .. 709/224
`(57)
`ABSTRACT
`Systems and methods for monitoring Web service transac
`tions include a monitoring server that is con?gured to monitor
`a Web service transaction. The monitoring server alloWs a
`user to describe a sequence of Web service requests that in
`combination de?ne a Web service transaction. The monitor
`ing server sends out the Web service requests in sequence to
`remote agents that are deployed in geographically diverse
`locations. The agents send the requests to the target Web
`service and the results are provided back to the monitoring
`server. The monitoring server receives the results and then
`dynamically constructs the next request in the series based on
`the sequence of requests from the user and data from the
`response to a prior request. The dynamically constructed next
`request is then sent to remote agents for execution and the
`results are provided to the monitoring server.
`
`SOA/ mash
`up server
`30
`
`Monitoring
`Server
`70
`
`SAP 1007
`IPR of U.S. Patent No. 8,346,894
`Page 1 of 12
`
`

`
`Patent Application Publication
`
`Jan. 1, 2009 Sheet 1 0f 5
`
`US 2009/0006614 A1
`
`10x
`
`Agent
`20
`
`Web
`Server
`50
`
`5
`
`SOA/ mash
`up server
`30
`
`Web
`Network
`4 0 ¢ Server
`60
`
`Monitoring
`Server
`70
`
`FIG. 1A
`
`A 00
`///
`Identify
`sequence of
`web service
`requests
`
`.
`
`m0
`/
`
`Send first/next
`request
`
`V
`
`A
`
`/120
`//
`Receive
`
`7
`
`response
`
`data
`
`‘
`
`FIG. 2
`
`Transform
`
`Y
`
`130/
`
`/150
`///
`
`Send modified
`request
`
`A
`
`Modify
`subsequent
`request with
`.
`response data
`140/
`
`SAP 1007
`IPR of U.S. Patent No. 8,346,894
`Page 2 of 12
`
`

`
`Patent Application Publication
`
`Jan. 1, 2009 Sheet 2 0f 5
`
`US 2009/0006614 A1
`
`http://www.youtube.com/api2_rest‘?user=webmetricsEng&dev_id=WWDnteO8wx8&method=youtube.users.|ist_fav0rite_videos
`
`FIG. 5A
`
`FIG. 5B
`
`Alert
`module
`300
`
`Graph
`module
`310
`
`Transaction
`module
`320
`
`Test
`module
`330
`
`Monitoring server 70
`
`FIG. 1B
`
`SAP 1007
`IPR of U.S. Patent No. 8,346,894
`Page 3 of 12
`
`

`
`Patent Application Publication
`
`Jan. 1, 2009 Sheet 3 0f 5
`
`US 2009/0006614 A1
`
`200
`
`210
`
`220
`
`230
`
`ldentlfy
`sequence of
`web service
`.
`requests
`
`|:|G_ 3
`
`.
`Send first/next
`request
`
`V
`
`7
`
`Receive
`response
`data
`
`‘
`7
`
`Parse
`response
`data
`
`A
`
`Use variable to
`construct
`subsequent ‘
`request
`260/
`
`Store variable
`in memory ‘
`
`250/
`
`v
`Assign portion
`of response
`data to
`variable
`240/
`
`<?xm| version=“1.0“ encoding=“UTF-8“ ?>
`<SOAP-ENV:Enve|ope xmlns:SOAP-ENV=“http://schemas.xmlsoap.org/soap/envelopel“
`xmlns:xsi=“http://www.w3.org/1999/XM LSchema-instance“
`xmlns:xsd=“http://www.w3.org/1999/XM LSchema“>
`<SOAP-ENV:Body>
`<ns1:doSpeIIingSuggestion xm|ns:ns1=“urn:Goog|eSearch“
`SOAP-ENV:encodingSty|e=“http://schemas.xm|soap.org/soap/encoding/“>
`<key xsi:type=“xsd:string">00000000O0000O0</key>
`<phrase xsi:type=“xsd:string“>britney speers<lphrase>
`</ns1:doSpellingSuggestion>
`</SOAP-ENV:Body>
`</SOAP-ENV:Envelope>
`
`FIG. 4A
`
`<?xm| version=“1.0“ encoding=“UTF-8“ ?>
`<SOAP-ENV:Enve|ope xm|ns:SOAP-ENV=“http://schemas.xm|soap.org/soap/envelopel“
`xmlns:xsi=“http://www.w3.org/1999/XM LSchema-instance“
`xmlns:xsd=“http://www.w3.org/1999/XMLSchema“>
`<SOAP-ENV:Body>
`<ns1:doSpeIIingSuggestionResponse xm|ns:ns1=“urn:Goog|eSearch“ SOAP
`ENV:encodingStyle=“http:llschemas.xmlsoap.org/soap/enc0ding/“>
`<return xsi:type=“xsd:string“>britney spears<lreturn>
`</ns1:doSpelIingSuggestionResponse>
`</SOAP-ENV:Body>
`</SOAP-ENV:Enve|ope>
`
`FIG. 4B
`
`SAP 1007
`IPR of U.S. Patent No. 8,346,894
`Page 4 of 12
`
`

`
`Patent Application Publication
`
`Jan. 1, 2009 Sheet 4 of 5
`
`US 2009/0006614 A1
`
`Assign '-Jariables
`
`FIG. 6
`
`V.-‘arlable Nanwe
`
`Variable RegEx
`
`its-gignn ‘H'.3r'§ai;sie§ Ex: Res-apurnxaz
`
`iiiiiiiii77
`
`PAGE 1 http://wvvw_youtube_com/api2_rest
`method get
`formdatauser=webmetricsEng&method=youtube.users.|ist_favorite_videos&dev_id=WWDnteO
`searchstring crash
`description REST
`
`END
`
`#STEPS 2
`
`PAGE 1 http://www_youtube_com/api2_rest
`pagetimeout 3
`method GET
`formdata user=webmetricsEng&dev_id=WWDnteO8wx8&method=youtube_users_|ist_favorite_videos&
`description REST
`END
`
`varRegexnth VIDEOID4 4 id>(.*?)</id
`varRegex VIDEOID1 id>(.*'?)</id
`varRegexnth VIDEOIDS 5 id>(.*?)</id
`resetheaders
`resettimeout
`
`PAGE 2 http://api.goog|e.com/search/beta2
`header Content—Type text/xml
`ormda arawnewline <'?xm| version=‘1.0‘ encoding=‘UTF-8"?>
`ormda arawnewline <SOAP-ENV:Enve|ope xmlnszSOAP-ENV=“http://schemas.xmlsoap.org/soap/envelope/" xm|ns:xsi=“http://
`www_w3_org/1999/XM Lschema-instance" xmlnszxsd="http://www_w3_org/1999/XMLSchema">
`ormda arawnewline
`<SOAP—ENV:Body>
`ormda arawnewline
`<ns1:d0G0og|eSearch xm|ns:ns1="urn:Goog|eSearch"
`ormda arawnewline
`SOAP-ENV:encodingSty|e="http://schemas.xmlsoap_org/soap/encoding/">
`ormda arawnewline
`<key xsi:type="xsd:string">4EuPakFQFH|5uVHBmSfazd9bSrYa9y+Z</key>
`ormda arawnewline
`<q xsi:type=“xsd:string“><VAR V|DEO|D5></q>
`ormda arawnewline
`<start xsi:type="xsd:int“>0</start>
`ormda arawnewline
`<maxResu|ts xsi:type="xsd:int">‘|0</maxResu|ts>
`ormda arawnewline
`<fi|ter xsi:type=“xsd:boo|ean">true<lfi|ter>
`ormda arawnewline
`<restrict xsi:type="xsd:string"></restrict>
`ormda arawnewline
`<safeSearch xsi:type="xsd:boolean“>fa|se</safeSearch>
`ormda arawnewline
`<|r xsi:type="xsd:string"></|r>
`ormda arawnewline
`<ie xsi:type="xsd:string“>|atin1</ie>
`ormda arawnewline
`<oe xsi:type=“xsd:string">|atin1</oe>
`ormda arawnewline
`</ns1:doGoog|eSearch>
`ormda arawnewline
`</SOAP-ENV:Body>
`ormda arawnewline </SOAP-ENV:Enve|ope>
`pagetimeout 3
`method POST
`searchstring YouTube.com
`description SOAP
`END
`
`resetheaders
`resettimeout
`
`FIG. 7C
`
`SAP 1007
`
`IPR of U.S. Patent No. 8,346,894
`Page 5 of 12
`
`SAP 1007
`IPR of U.S. Patent No. 8,346,894
`Page 5 of 12
`
`

`
`Patent Application Publication
`
`Jan. 1, 2009 Sheet 5 of 5
`
`US 2009/0006614 A1
`
`header SOAPAction urn:Goog|eSearchAction
`header Content-'
`ype text/xml
`
`PAGE 1 http://api_goog|e.com/search/beta2
`method post
`ormda arawnew ine <?xm| version='1.0' encoding=‘UTF-8'?>
`'ormda arawnew ine <SOAP—ENV:Enve|ope xm|ns:SOAP—ENV="http:l/schemasxmlsoap.org/soap/envelope/" xm|ns:xsi="http:lI
`wvvw.w3_org/1999/XMLSchema-instance" xm|ns:xsd="http://www_w3_org/1999/XMLSchema">
`ormda arawnew ine <SOAP-ENV:Body>
`ormda arawnew ine
`<ns1:doGoog|eSearch xm|ns:ns1="urn:Goog|eSearch"
`'ormda arawnew ine
`SOAP—ENV:enCodingStyle=“http://schemaexmlsoap.org/soap/encoding/“>
`'ormda arawnew ine
`<key xsi:type=“xsd:string">4EuPakFQFHI5uVHBmSfazd9bSrYa9y+Z</key>
`ormda arawnew ine
`<q xsi:type="xsd:string“>Webmetrics</q>
`'ormda arawnew ine
`<start xsi:type="xsd:int“>0</start>
`'ormda arawnew ine
`<maxResu|ts xsi:type="xsd:int">10</maxResu|ts>
`ormda arawnew ine
`<fi|ter xsi :type="xsd:boo|ean“>true</fi|ter>
`'ormda arawnew ine
`<restrict xsi 2type="xsd:string"></restrict>
`'ormda arawnew ine
`<eafeSearch xsi:type="xsd:boolean“>fa|se</safeSearch>
`ormda arawnew ine
`<|r xsi:type="xsd:string“></|r>
`'ormda arawnew ine
`<ie xsi:type="xsd:string">|atin1</ie>
`'ormda arawnew ine
`<oe xsi:type=“xsd:string">|atin1</oe>
`ormda arawnew ine
`</ns1:doGoog|eSearch>
`'ormda arawnew ine <ISOAP—ENV:Body>
`'ormda arawnew ine </SOAP-ENV:Enve|ope>
`searchstring http://wvvw.webmetrics.com
`description SOAP
`END
`
`FIG. 7B
`
`
`
` Secondary
`Memory 558
`
`Processor
`
`CommunicationBus554
`
`Removable
`
`Storage Drive
`
` Interface 574
`
`Main Memory
`556
`
`Communication
`
`FIG. 8
`
`SAP 1007
`
`IPR of U.S. Patent No. 8,346,894
`Page 6 of 12
`
`SAP 1007
`IPR of U.S. Patent No. 8,346,894
`Page 6 of 12
`
`

`
`US 2009/0006614 A1
`
`Jan. 1, 2009
`
`MONITORING WEB SERVICE
`TRANSACTIONS
`
`RELATED APPLICATION
`[0001] The present application claims priority to US. pro
`visional patent application Ser. No. 60/946,931 ?led Jun. 28,
`2007, Which is incorporated herein by reference in its entirety.
`
`BACKGROUND
`[0002] 1. Field of the Invention
`[0003] The present invention is generally related to Website
`monitoring and more speci?cally related to the monitoring of
`Web service transactions.
`[0004] 2. RelatedArt
`[0005] In conventional Web service monitoring, it is di?i
`cult to test an online Web service from a variety of remote
`locations on a regular interval. Typical solutions hard code a
`series of requests and related values for use in each step of the
`Web service transaction. These conventional solutions are
`problematic and very labor intensive because they require
`manually updating the hard coded values each time the Web
`service transaction is monitored. Data entry errors are intro
`duced by operators that result in incorrect results that then
`require additional monitoring at high labor cost. Additionally,
`the conventional solutions are unable to scale up to the nec
`essary bandWidth required to monitor a Web service transac
`tion from remote locations on a regular interval. Therefore,
`What is needed is a system and method that overcomes these
`signi?cant problems found in the conventional systems as
`described above.
`
`SUMMARY
`[0006] Accordingly, described herein are systems and
`methods for monitoring Web service transactions. A monitor
`ing server is con?gured to monitor a Web service transaction,
`Which is de?ned as a series of steps that include requests to
`one or more Web services that can be hosted by one or more
`different servers such that each step can be discrete Web
`service request. The monitoring server alloWs a user to
`describe a sequence of Web service requests that in combina
`tion de?ne a Web service transaction. The monitoring server
`sends out the various Web service requests in sequence to
`remote agents that are deployed in geographically diverse
`locations. The agents send the requests to the target Web
`service and the results are provided back to the monitoring
`server. The monitoring server then dynamically constructs
`the next request in the series based on the sequence of
`requests from the user and data from the response to a prior
`request and sends the dynamically constructed next request to
`remote agents for execution. In this fashion a Web service
`transaction can be monitored in a Way that approximates the
`actual use of Web services in the ?eld. Other features and
`advantages of the present invention Will become more readily
`apparent to those of ordinary skill in the art after revieWing the
`folloWing detailed description and accompanying draWings.
`BRIEF DESCRIPTION OF THE DRAWINGS
`[0007] The details of the present invention, both as to its
`structure and operation, may be gleaned in part by study of the
`accompanying draWings, in Which like reference numerals
`refer to like parts, and in Which:
`
`[0008] FIG. 1A is a netWork diagram illustrating an
`example system for Web service transaction monitoring
`according to an embodiment of the present invention;
`[0009] FIG. 1B is a block diagram illustrating an example
`monitoring server according to an embodiment of the present
`invention;
`[0010] FIG. 2 is a How diagram illustrating an example
`process for using data in a subsequent transaction according
`to an embodiment of the present invention;
`[0011] FIG. 3 is a How diagram illustrating an example
`process for variable assignment according to an embodiment
`of the present invention;
`[0012] FIGS. 4A and 4B are code sections that illustrate an
`example of a Web service SOAP request according to an
`embodiment of the present invention;
`[0013] FIGS. 5A and 5B are code sections that illustrate an
`example of a Web service REST request according to an
`embodiment of the present invention;
`[0014] FIG. 6 is a dialog box illustrating an example inter
`face for de?ning a variable according to an embodiment of the
`present invention;
`[0015] FIG. 7A is a code section that illustrates an example
`REST Web service script according to an embodiment of the
`present invention;
`[0016] FIG. 7B is a code section that illustrates an example
`SOAP Web service script according to an embodiment of the
`present invention;
`[0017] FIG. 7C is a code section that illustrates an example
`Web service transaction script according to an embodiment of
`the present invention; and
`[0018] FIG. 8 is a block diagram illustrating an example
`computer system that may be used in connection With various
`embodiments described herein.
`DETAILED DESCRIPTION
`[0019] Certain embodiments as disclosed herein provide
`systems and methods for monitoring of Web service transac
`tions. For example, one method as disclosed herein alloWs for
`a monitor server to receive a sequence of Web service requests
`from a user. The monitor server then causes each request to be
`sent to the particular Web service and subsequent requests are
`dynamically constructed such that they may include informa
`tion received by the monitor server in response to a prior Web
`service request. The result of the processing of the sequence
`of Web service requests alloWs the Web service transaction to
`be automatically monitored Without user involvement.
`[0020] After reading this description it Will become appar
`ent to one skilled in the art hoW to implement the invention in
`various alternative embodiments and alternative applications.
`HoWever, although various embodiments of the present
`invention Will be described herein, it is understood that these
`embodiments are presented by Way of example only, and not
`limitation. As such, this detailed description of various alter
`native embodiments should not be construed to limit the
`scope or breadth of the present invention as set forth in the
`appended claims.
`[0021] Web services are becoming an industry standard
`mechanism of sharing data and they enable the linking
`together (serial or parallel or both) of applications hosted by
`one or more Web servers. An example of a Web service trans
`action can be illustrated by a simple car insurance application.
`An applicant ?lls out a request for insurance form at a par
`ticular car insurance Website. The data collected in the insur
`ance form is then encapsulated into a Web service friendly
`
`SAP 1007
`IPR of U.S. Patent No. 8,346,894
`Page 7 of 12
`
`

`
`US 2009/0006614 A1
`
`Jan. 1, 2009
`
`format @(ML, J SON, etc). That data is then sent using REST
`or SOAP to the department of motor vehicles (“DMV”) Web
`service for a record check. The response from the DMV
`comes back and is modi?ed and then submitted to a state and
`or federal government crime Web service to see if the appli
`cant has a criminal history. The response from the crime Web
`service comes back and is modi?ed then submitted to a ?nan
`cial Web service for a credit check. The aggregation of all of
`the responses from the various Web services is then packaged
`and provided to the particular car insurance Website that Was
`offering the insurance product Where the decision Weather or
`not to approve the application can be made.
`[0022] Another example of a Web service transaction is a
`mashup. For example, at a real estate Website, a user enters the
`Zip code of the area in Which he or she is interested in pur
`chasing or renting a home. The Zip code is then sent to a
`classi?eds Web service to determine What rental and for sale
`listings are available in that Zip code. The data from the
`classi?eds Web service is then supplied to a mapping Web
`service and the user is then presented With a map of apart
`ments and or homes that are for rent or sale in the desired area
`code.
`[0023] Web services alloW machines to be interoperable
`regardless of architectural differences in softWare or hard
`Ware. A Web service receives a request for information, pro
`cesses the request, and returns the information requestedi
`typically in the form of extensible markup language (“XML”)
`data or similar languages used in the transmission of infor
`mation across the internet. Types of Web services include
`SOAP (formerly an acronym for Simple Object Access Pro
`tocol although that de?nition for the acronym Was dropped
`With SOAP version 1.2), representational state transfer
`(“REST”), hypertext transfer protocol/ hypertext markup lan
`guage (“HTTP/HTML”), and extensible markup languagei
`remote procedure call (“XML-RPC”).
`[0024] SOAP is a standard maintained by the World Wide
`Web Consortium (“W3C”). SOAP Web services are de?ned
`by a Web services description language (“WSDL”) ?le. This
`?le contains the information needed to generate a properly
`formatted request and describes the format of the response.
`Setting up Web services to monitor a SOAP Web service
`requires a properly con?gured WSDL ?le. SOAP requests are
`typically sent using a POST HTTP request method.
`[0025] REST does not have a standard that is maintained by
`the W3C. Accordingly, the de?nition of the format for
`requests and replies are designed and implemented by the
`company/person offering the Web service. REST usage is
`very popular because of its simplicity and ease of implemen
`tation. REST requests are typically sent using a GET HTTP
`request method Where all parameters are passed in the URL.
`HoWever, the response from the Web service is typically
`XML, JavaScript Object Notation (“JSON”) or something
`similar. POST can also be used as a request format for REST.
`[0026] HTTP/HTML/ TEXT is used for those Web services
`that return strings of text or HTML rather than XML. This
`type of Web service is similar to REST in that the format for
`the request and response is de?ned by the designer of the Web
`service. One example of this is requesting information from a
`page that Will do some sort of processing and returns a mes
`sage indicating Whether it Was successful or not.
`[0027] Hash message authentication code (“HMAC”) and
`message-digest algorithm 5 (“MD5”) are types of message
`authentication codes calculated using a cryptographic hash
`function in combination With a secret key. This is used in the
`
`context of Web services to encode the request in such a Way as
`to ensure its integrity, and to distinguish one request from
`another. For example, pieces of the Web service request can be
`encoded using HMAC or MD5 algorithms. Other encoding
`techniques may also be used as Will be understood by those
`skilled in the art.
`[0028] FIG. 1 is a netWork diagram illustrating an example
`system 10 for Web service transaction monitoring according
`to an embodiment of the present invention. In the illustrated
`embodiment, the system 10 comprises a netWork 40 that
`communicatively links a plurality of agents 20 (only one is
`shoWn for simplicity), a plurality of Web servers 50 and 60
`(only tWo are shoWn for simplicity), a monitoring server 70,
`and an service oriented architecture (“SO ”)/mash-up server
`30. Each of the computing devices shoWn in FIG. 1 is con
`?gured With an associated data storage area.
`[0029] In practice, the SOA server 30 employs the service
`oriented architecture to provide mash-ups to consumers or for
`internal use, for example to track sales information, account
`ing information, or the like. The various Web services used by
`the SOA server 30 may be hosted by a variety of Web servers
`such as Web server 50 and Web server 60 as Well as other Web
`servers (not shoWn). The SOA server 30 has a need to monitor
`these various Web servers (including 50 and 60) to ensure that
`they are operating as needed. In one embodiment, a mashup
`could also be correlated by a Web broWser alone Without the
`need for a separate server doing the aggregation.
`[0030] The monitoring server 70 is con?gured to perform
`the monitoring of Web service transactions. The monitoring
`server 70 is con?gured to monitor a single Web service, for
`example a Web service provided by Web server 50. The moni
`toring server 70 is also con?gured to monitor a plurality of
`Web services that are intentionally used in sequence to
`achieve a desired result. Each of the plurality of Web services
`may be hosted by a separate Web server (e. g., Web server 50).
`Alternatively, a single Web server 50 may also host more than
`one Web service. Additionally, the use of Web services as part
`of a Web service transaction can be sequential and may also be
`in parallel.
`[0031] The monitoring server 70 alloWs for a sequence of
`Web service requests to be created and this sequence of
`requests is carried out by the various agents 20 under the
`control of the monitoring server 70. The monitoring server 70
`is also con?gured to store data that is received in response to
`a request, for example in data storage or as one or more
`variables in volatile memory. The response data can then be
`used by the monitoring server 70 in subsequent requests.
`Advantageously, this use of response data for subsequent
`requests approximates the fashion in Which SOA servers such
`as SOA server 30 actually employ Web services that may be
`provided by Web servers 50 and 60.
`[0032] The monitoring server 70 is also con?gured to vali
`date the data that is received in response to the various
`requests that are processed in order to determine the status of
`the various Web servers 50 and 60 that are used in a sequence
`of Web service requests that de?ne a Web service transaction.
`[0033] The monitoring server provides the ability to assign
`values from a response at any given step to a variable and
`reuse the data stored in that variable in any subsequent
`requests. This ability alloWs the monitoring server to do an
`nth match for anything in the page. For example, FIG. 6 is a
`dialog box illustrating an example interface for de?ning a
`variable according to an embodiment of the present invention.
`As shoWn, the variable being de?ned is named “TITLE” and
`
`SAP 1007
`IPR of U.S. Patent No. 8,346,894
`Page 8 of 12
`
`

`
`US 2009/0006614 Al
`
`Jan. 1, 2009
`
`the variable is to be assigned the contents between the
`“Title>” and “</Title” strings. The nth match column is
`optional in that if a value is not speci?ed, it Will default to the
`?rst match hoWever if the strings “Title>” and “</Title”
`appear in multiple places, it Will return the nth match. As
`shoWn in FIG. 6, n is the 2nd match.
`[0034] For example, given a Web service that provides the
`folloWing response:
`
`[0035] To assign the value 123456789 to a variable called
`ITEM, the Word “ITEM” is entered into the variable name
`?eld, the value “item>(.*?)</item” is entered into the variable
`regex ?eld and the third ?eld is either left blank or the number
`one is entered into the nth match ?eld. When the above data is
`receive in response to a request to the Web service, the
`response Will be parsed and the variable ITEM Will be
`assigned the value 123456789. Alternatively, to assign the
`value 987654312 to the variable ITEM, the value in the “nth
`match” ?eld can be set to the number tWo.
`[0036] FIG. 1B is a block diagram illustrating an example
`monitoring server 70 according to an embodiment of the
`present invention. In the illustrated embodiment, the moni
`toring server 70 comprises an alert module 300, a graph
`module 310, a transaction module 320, and a test module 330.
`[0037] The alert module 300 is con?gured to provide an
`alert of some sort (e.g., email, text message, phone call) in
`response to a certain event. For example, timeout errors,
`connectivity errors, and content errors may each cause an
`alert. Advantageously, if a Web service provides XML
`responses, alerts (e. g., diagnostic emails) include both header
`information and content. In one embodiment, the diagnostic
`email is sent With one ?le attached that includes the header
`information and a second ?le attached that includes the XML
`content so that When a user opens an XML attachment, it Will
`render properly in the broWser, otherWise the broWser Will try
`to interpret it as html and only display the contents of the tags
`and not the tags themselves.
`[0038] The graph module 310 is con?gured to provide
`illustrative information regarding the status of individual Web
`services and Web service transactions that are being moni
`tored. Graphs for individual Web services and Web service
`transactions include (1) load time graphs (response time by
`period, transaction step averages, transaction steps over
`time); (2) city graphs (response timeicity by city (average),
`response time4city by city (scatter), uptime & average
`response timeiall cities); (3) error graphs (errors by type,
`errors by time); and (4) performance trending graphs (uptime
`table, transfer rate, performance variation, Worst hour/Worst
`day). Other graphs can also be included.
`[0039] The transaction module 320 alloWs a user to con?g
`ure a Web service transaction that includes a plurality of
`requests. The transaction module alloWs a user to de?ne vari
`ables that Will store data that can be used in subsequent
`requests. The data in a variable can be prede?ned static data or
`it may be dynamically de?ned from prior response data or
`from data in a local ?le or database that may change over time.
`[0040] Additionally, for SOAP requests using the POST
`method, the transaction module 320 alloWs users to con?gure
`
`?elds that include: (a) service location: Where the Web service
`is located; (b) SOAPAction: usually optional but some Web
`services require it to be set in the header of the transaction; (c)
`XML message: the entire request that Will be sent to the Web
`service; (d) verify keyWord: keyWord We can use to verify a
`successful transaction; and (e) error keyWord: keyWord We
`can use to verify an unsuccessful transaction.
`[0041] For SOAP requests using the GET method, the
`transaction module 320 alloWs users to con?gure ?elds that
`include: (a) service location: Where the Web service is
`located; (b) parameter name/value pair4e.g., parameter
`name: name of data to be passed/parameter value: value of
`data to be passed; (c) complete request: users can opt to use
`this option to set the URL With all of the data included in the
`URL; (d) verify keyWord: keyWord to verify a successful
`transaction; and (e) error keyWord: keyWord to verify an
`unsuccessful transaction.
`[0042] For REST requests using the POST method, the
`transaction module 320 alloWs users to con?gure ?elds that
`include: (a) service location: Where the Web service is
`located; (b) XML message: the XML block that We Will
`submit to the Web service; (c) verify keyWord: keyWord to
`verify a successful transaction; and (d) error keyWord: key
`Word to verify an unsuccessful transaction.
`[0043] For REST requests using the GET method, the
`transaction module 320 alloWs users to con?gure ?elds that
`include: (a) service location: Where the Web service is
`located; (b) parameter name/value pair4e.g., parameter
`name: name of data to be passed/parameter value: value of
`data to be passed; (c) complete request: users can opt to use
`this option to set the URL With all of the data included in the
`URL; (d) verify keyWord: keyWord to verify a successful
`transaction; and (e) error keyWord: keyWord to verify an
`unsuccessful transaction.
`[0044] For Web service requests that return HTML or
`TEXT, the transaction module 320 alloWs users to con?gure
`?elds that include: (a) service location: Where the Web service
`is located; (b) parameter name/value pairie.g., parameter
`name: name of data to be passed/parameter value: value of
`data to be passed; (c) complete request: users can opt to use
`this instead of the parameter name/value pair but Will have to
`specify the entire URL; (d) verify keyWord: keyWord to verify
`a successful transaction; and (e) error keyWord: keyWord to
`verify an unsuccessful transaction.
`[0045] Once a Web service transaction has been set up for
`monitoring, the transaction module 320 is con?gured to
`execute the monitoring in an automatic fashion. This function
`may also be separated out in alternative embodiments to
`provide separation betWeen live production monitoring and
`the creation and testing of monitoring sequences.
`[0046] The test module 330 is con?gured to alloW manual
`or automated testing of a Web service monitoring sequence to
`ensure the settings are correct before automated monitoring
`begins.
`[0047] FIG. 2 is a How diagram illustrating an example
`process for using response data from a prior request in a
`subsequent request according to an embodiment of the
`present invention. In one embodiment, this process may be
`implemented by the monitoring server previously described
`With respect to FIG. 1. Initially, in step 100, the monitoring
`server identi?es a predetermined sequence of Web service
`requests that are desired to be monitored. This sequence of
`Web service requests de?ne a Web service transaction and
`may be provided by a user through a user interface on the
`
`SAP 1007
`IPR of U.S. Patent No. 8,346,894
`Page 9 of 12
`
`

`
`US 2009/0006614 A1
`
`Jan. 1, 2009
`
`monitoring server. The sequence of Web service transactions
`can be predetermined by an administrator of the SOA server,
`for example.
`[0048] Next, in step 110 the ?rst request in the Web service
`transaction is sent to the provider of the Web service. In one
`embodiment, the request may be sent to the Web service
`provider by a plurality of geographically diverse agents oper
`ating under the control of the monitoring server. Next, in step
`120 the response is received from the Web service provider. If
`the data from the response is to be transformed (i.e., used in a
`subsequent request), as determined in step 130, a subsequent
`request in the predetermined list is then modi?ed With the
`prior response data. The modi?ed request is then sent, as
`shoWn in step 150. In one embodiment, the modi?ed request
`may be the next request that is sent as part of the overall Web
`service transaction or it may be a subsequent request that is
`sent tWo or more requests later. If the data is not to be trans
`formed, the monitoring server then sends the next request as
`shoWn in step 110. The process continues until the sequence
`of Web service requests that comprise the Web service trans
`action is exhausted. The transformation process can modify
`data used in the most recent response, remove data, add
`prede?ned static data or add dynamic variables, e.g., date,
`time, and random numbers, just to name a feW types of
`dynamic data.
`[0049] FIG. 3 is a How diagram illustrating an example
`process for variable assignment according to an embodiment
`of the present invention. In one embodiment, this process may
`be implemented by the monitoring server previously
`described With respect to FIG. 1. Initially, in step 200, the
`monitoring server identi?es a predetermined sequence of Web
`service requests that are desired to be monitored, as described
`With respect to FIG. 2. Next, in step 210 the ?rst request is sent
`to the Web service provider and then in step 220 the response
`is received from the Web service provider. In step 230, the
`response is parsed by the monitoring server to identify par
`ticular portions of the response data. These one or more
`particular portions of the response data are then assigned to
`variables in step 240 and the variables are stored in memory
`on the monitoring server for later use, as shoWn in step 250. In
`alternative embodiments, the portion of response data can be
`stored in one or more ?les, stored in a database, a register or
`some other form of storage that does not involve the use of a
`variable. In a subsequent request, either the next request or
`perhaps tWo or three requests later in the Web service trans
`action, the data from one or more variables can be used to
`construct the request, as shoWn in step 260. This dynamically
`constructed request is then sent by the monitoring server, as
`shoWn in step 210. As previously described With respect to
`FIG. 2, When stored data is used to dynamically construct a
`subsequent request, the subsequent request can be modi?ed
`by changing, deleting, or adding static or variable driven data
`to the request.
`[0050] FIGS. 4A and 4B are code sections that illustrate an
`example of a Web service SOAP request sent to a spelling
`suggestion Web service (4A) and the corre