Patent Application
20070164849
The subject matter described herein relates to enterprise software with contextual support.
As enterprise software deployments increase in complexity, the costs for supporting such deployments is additionally increasing (and comprises a large portion of the total cost of ownership of enterprise software). With conventional systems, the support load directly scales up with a number of users. Therefore, there is little, if any, cost savings in large deployments. This lack of cost savings is based, in part, on the fact that such arrangements are often inefficient (e.g., support requests are often not routed to the correct entities), fault-prone (e.g., users often do not adequately describe the situation requiring support and its context), and time-intensive (e.g., the situation requiring support cannot be simulated). Moreover, conventional support processes are often not repeatable as a structured mechanism for symptom description and cause identification, nor do such processes optimally resolve identified errors.
An incident message generated by an end user may be received that includes user-generated input data and collected context data both characterizing a state of a computing system. Subsequently, the incident message may be assigned and routed to a key user based on the context data (e.g., using one or more attributes of the context data). The key user may then act to initiate an implementation of a solution to the incident message which optionally results in a solution message being routed or otherwise transmitted to the end user notifying him or her about the solution to the incident message.
The incident message may be initiated by a user activating one or more graphical user interface elements integrated into a software application operating on the computing system. For example, a help button may be embedded on each page presented by the software application. Activating the help button may cause a support request window or form to be presented to the end user requesting further information associated with an incident.
After the user-generated input (e.g., after the user has filled out the support request form), the context data may be collected. The context data may comprise diagnostic data associated with the operation of the computing system.
In attempting to resolve the incident associated with the incident message (also referred to simply as the incident message), the key user may manually enter in a proposed solution (which may occur after, for example, searching a knowledge base or utilizing a wizard tool), or it may hand off the incident message to a backend system (which may reside on a remote node). The backend system may, in turn, poll a knowledge base (which may be local to the backend system) to obtain one or more predefined solutions associated with at least a portion of the content data (e.g., an attribute). Optionally, the backend system may route the incident message to a support user (e.g., an expert user) that can determine an appropriate solution to the incident message—which solution is transmitted back to the key user (or alternatively, which is automatically implemented).
The incident message may be routed to the key user by queuing the message in a work list associated with the key user and/or by e-mailing the incident message to the key user. Similarly, the solution message may be queued in a work list associated with the end user and/or e-mailed to the end user.
After the solution message has been routed to the end user, the end user may provide feedback data to confirming whether the solution resolves an incident associated with the incident message. This feedback data may be provided, for example, in a form other graphical user interface. However, if the feedback data indicates that the incident was not properly resolved, the feedback and the data may be sent back to the key user (or some other user) to reprocess.
In some variations, each generated solution message may be stored in a knowledge base repository. The knowledge base repository may be used to identify appropriate solutions for subsequent incident messages (using, for example, attributes of the context data).
In an interrelated aspect, an incident message generated by an end user may be received that includes user-generated input data and collected context data both characterizing a state of a software application. Next, the incident message may be assigned and routed to a key user based on the context data. The key user, using the incident message, may initiate an implementation of a solution to the incident message. A solution message that characterizes the solution may be routed to the end user. The end user may then determine whether or not to implement the solution (as opposed to the key user making this determination).
In yet another interrelated aspect, an incident message generated in response to and characterizing a monitored change in a state of a computing system may be received. Based on the data contained in the incident message, a key user is assigned to and provide with the incident message. Thereafter, the key user main implement a solution to the incident message. Optionally, a solution message notifying the end user of a solution to the message may be routed to the end user.
Computer program products, which may be embodied on computer readable-material, are also described. Such computer program products may include executable instructions that cause a computer system to conduct one or more of the method acts described herein.
Similarly, computer systems are also described that may include a processor and a memory coupled to the processor. The memory may encode one or more programs that cause the processor to perform one or more of the method acts described herein.
The subject matter described herein provides many advantages. By providing intelligent context-specific support, a number of utilized support staff may be reduced and such support staff may have narrowly defined areas of expertise thereby minimizing training costs. Moreover, the subject matter described herein allows for efficient and reliable support processes. The processes are efficient in that they readily identify a cause of an incident or error, assign such incident to an appropriate support person, provide required information to simulate or otherwise diagnose the error situation, and apply an optimal appropriate resolution to the incident. The support processes are repeatable in that previously identified causes and resolutions for incidents, problems or errors may be accessed and applied. In addition, the subject matter described herein may be utilized to develop and organize a knowledge base based on the context specific support requests.
Specifically, the subject matter described herein, depending on the desired implementation allows for one or more of the following advantages: an infrastructure for an end user to address incidents; reduced support for typical usability problems; reduced efforts required to create a service ticket including a required level of detail; provision of diagnostic context data which is time sensitive; simulation of system errors and errors caused by the end user; provision of relevant data from a system/technical layer relating to involved components (e.g., business objects) and a configuration of such layer (e.g., determinations and definition of which determinations are active, how the determinations are configured, and which determination was called by the business object in the certain case); automated and rapid provision of context-specific support solutions including software updates; and the like.
The details of one or more variations of the subject matter described herein are set forth in the accompanying drawings and the description below. Other features and advantages of the subject matter described herein will be apparent from the description and drawings, and from the claims.
Like reference symbols in the various drawings indicate like elements.
While utilizing the business system 206, an end user may identify, at 210, an error or other problem with a software application. Thereafter, the end user may, at 212, trigger or otherwise initiate the generation of an incident message. This message may be created, for example, by the end user activating an element within a graphical user interface presented by the software application (e.g., a help button, etc.). Activation of the graphical user interface element may result in a window containing a form prompting the end user to provide information relating to the incident (e.g., a written description and/or categorization of the incident).
After the end user has initiated the generation of the incident message, the business system 206 may, at 214, collect or otherwise obtain context data associated with the state of the software application at the time the end user initiated the generation of the incident message. The context data, may, in some variations, comprise support information from all layers in the architecture. Thereafter, the incident message may be generated by the business system 206. The incident message may contain data associated with the input received from the end user (e.g., a description of the incident as recounted by the end user) as well as the collected context data. After the incident message has been generated, it may, at 216, be sent to the service desk 208.
The service desk 208, upon receiving the incident message, may at 218, determine a key user (e.g., processor) to handle the incident message, based at least in part, on the context data encapsulated in the incident message. The incident message, at 244, may be persisted. Once this determination has been made, the incident message (or data associated therewith) may, at 220, be transmitted to a work list associated with the key user.
The key user may, at 222, process the incident message in any of a variety of ways. In one aspect, the key user may simply manually determine/assign a solution for the incident message. Alternatively, the key user, may, at 224, conduct a search for a solution (e.g., a local search, a search of a remote database, etc.), using, for example, a key word search based on information in the incident message. The service desk 208, may optionally employ, at 228, analysis and/or resolution wizards which present the key user with a series of sequential interrogatories which can be used to identify an appropriate solution or more specifically define the cause of the incident. Additionally, the service desk, 208, may optionally, at 230, initiate the modification of the software application operating on the business system 206 (e.g., sending an update, patch, etc.).
In one optional variation, the incident message may, at 226, be forwarded to the backend system 204. This forwarding to the backend system 204 may be initiated automatically or in response to an input by the key user. The automatic forwarding may be selective based on the contents of the collected data and/or the input from the end user (e.g., forwarding only occurs for certain types of incidents). At the backend system 204, the incident message is processed by a global support system 232. In one variation, the global support system 232 is operable to process a message so that a knowledge base 236 may be polled, at 234, to determine whether there are any known solutions associated with the data encapsulated in the incident message (which may be persisted at 238). In another variations, the global support system 232 routes the received incident message to one or more support users to determine a resolution for the incident message. One or more solutions may be transmitted by the global support system 232 back to the service desk 208 after the knowledge base 236 is accessed (or the support user determines.
The key user may, at 240, initiate a resolution message after the message has been processed. The service desk 208 may then, at 242, send a resolution message to the business system 206. The resolution message may comprise a solution including instructions for the end user to handle or otherwise correct the incident and/or it may comprise a solution including data operable to automatically handle the incident. At 246, the end user may access the resolution message (or data associated therewith) and/or obtain a notification about the solution in his or her worklist. Thereafter, the end user may, at 248, optionally provide feedback regarding the solution (e.g., the end user fills out a customer feedback form).
In some variations, rather than having the end user initiate the incident message, the incident message may be automatically initiated upon a detection of an error or other situation requiring support in the computing system. With such an arrangement, the end user does not, at 212, trigger the incident message. However, the context data may still be collected, at 214, so that the context data is sent to the service desk 208 at 216. The state of the application and/or computing system may be monitored in order to detect any modification of associated parameters that might require support.
The generated solutions may be used to populate a knowledge base data repository. Thereafter, for each new incident message, attributes within the associated context data may be mapped to one or more solutions within the knowledge base data repository. This mapping may occur automatically, or in the alternative, may occur in response to key word searches conducted by the key user.
The following provides a sample process flow which commences with an end user working on a page 308 rendered by a frontend server 302. The page 308 may present a help UI 310 in which the end user activates a “Request Support” button. As an alternative, the page 308 may present an application UI 312 in which the user may activate the “Request Support” button directly within an Application UI 312. A client side event is sent (at 1) from the Help UI 310 to the Application UI 312. An event handler within the Application UI 312 receives the event, and starts processing it. The event handler calls (at 2) a frontend::get_diagnostics service from a Frontend Runtime 314 to determine the frontend context, (e.g. role, work center, content of portal fields, etc.). In addition, a support context GUID (SC_GUID) is determined, that will be used for storing and retrieving the support context later.
The event handler triggers (at 3) a “dump diagnostic context” action. The SC_GUID and the frontend context are passed as parameters. The action with its parameters is received by a service manager 316 within a first backend 304. The service manager starts processing the action. The service manager 316 loops (at 4) over all active business objects 320 (transient context data) and retrieves business object specific context information from each business object 318 using a application::get_diagnostics core service.
The service manager 316 collects (at 5) the generic part of the support context (e.g. registered services, technical data, buffer data from the ESI layer, configuration and other environment data). Data from the ESI framework is retrieved within the service manager 316 itself. For obtaining context data from the technical layers, the service manager 316 uses a system::get_diagnostics service from Lifecycle Management Context Services 322.
The service manager 316 (at 6) writes all the context packages collected to a database 324, using a second database channel 326, and commits (on the second database channel—therefore the regular transaction handling for the business objects is not affected). The “dump action” processing is now finished, and control returns to the event handler of the application UI.
The event handler in the Application UI 312 uses (at 7) object based navigation (OBN), to open the request support UI 326 within a new transaction. The SC_GUID is passed as a parameter with the URL that is created by the OBN. The request support UI 326 instantiates (at 8) a new support context business object (SC-BO) 328 encapsulating context data 330, by calling the create core service of the SC-BO 328. The create service receives the SC_GUID. Using the SC_GUID, the implementation of the create core service reads (at 9) the context data from the database 324, extracts the data and builds up the structures of the SC-BO 328.
Relevant data from the SC-BO 328 can be displayed (at 10) in the request support user interface 326 (e.g. a calculated value for the category). The end user enters additional data within the request support UI 326, and then presses the “Send” button. In turn, the save core service of the SC-BO 328 is triggered.
An agent manager 330 is (at 11) triggered by the framework. The agent manager 330 (at 12) raises the appropriate event within an event manager 332 The event manager 332 (at 13) calls the an outbound process agent 334 having a message 336 encapsulated therein for the SC-BO 328.
The outbound process agent 334 uses the SC-BO retrieve core service, to read the support context data 330 (that was built up at 9). The outbound process agent 334 converts the support context data 330 received into an XI message (the SC_MESSAGE). The outbound process agent 334 calls an outbound XI proxy 338 and passes the SC_MESSAGE that was previously created as a parameter. The outbound XI proxy 338 sends the message to the inbound XI proxy 340 of the backend 2306 (e.g., the receiving service desk system 208). The XI proxy 340 in the receiving system 308 identifies the document type and determines which inbound process agent 342 has to be called, in this case a specific one for inbound processing of the support context. This process agent 342 is called (at 17), and the XI message is being passed to the process agent 342.
The process agent 342 extracts the data from the XI message and calls the create core service of the service request business object 344. Part of the data in the SC_MESSAGE is stored directly in the service request (e.g. the user is stored as the partner role “requester”), all data that has no process relevance or correspondence in the service request business object 344 is stored as a “Support Context” XML attachment 346. At the end of this process chain, the incident is stored as a CRM service request in the service desk system, and can be further processed.
The details of the implementation depend on the type of the specific application UI 326 (e.g., a transactional UI created with Web Dynpro for Java, etc). For a pattern based Web Dynpro application, the help link or support button may be integrated into any floor plan. Sample floor plans include object instance, guided activity, quick activity, and the like. The object instance and guided activity floor plans may have a help link within their object identification pattern, and thus also provide access to the embedded support functionality. With a quick activity floor plan, a support button or link may be integrated therein.
In some variations, a help button/support link may be integrated into an error message (i.e., when an incident error is presented, a help button/support link is also presented). By integrating the help button, the context data includes a reference to the specific error identified in the error message.
The Request Support UI 326 allows the end user to enter a limited amount of additional data to describe the incident, such as priority, a short text entry, a long text description, and the like. Additional entered data may include a category (to be selected from an hierarchical category list), to describe the incident in predefined terms (e.g. hardware—printer; software—Customer Relationship Management—Sales—Pricing). The category should be pre-filled/populated based on the context of the incident (e.g. software—SAP—CRM) and to allow a refinement by the end user (e.g., to select among CRM specific categories, like Pricing, Partner Determination, ATP Check). A telephone number and e-mail address may also be included so that an end user may opt to be notified regarding a resolution of the incident by a telephone call/SMS or e-mail (which alternatively may be derived from data associated with the end user).
The Request Support UI 326 is an application user interface for the Support Context Business Object 328, however it does not display diagnostic information. In addition, the Request Support UI 326 with the Support Context Business Object 328 represents a transaction (running in a new session) which is parallel to the original application transaction (the session to which the <ESA Business Objects 318> belongs to). Therefore, the data can be saved and processed, independently from saving or processing of the original application. Instead of a “Save” button, the Request Support UI 326 provides a “Send” button. When this button is pressed, the save event is triggered on the SC business object 328.
The <ESA Business Objects> 318 denotes all application business objects, which are in memory within the user's application session. These business objects 318 provide the application::get_diagnostics core service, which is called by the service manager 316. With this arrangement, application specific diagnostic data from the user's context may be obtained, such as internal data from the BO layer 406 that is not modeled in the ESI layer 404, such as contents of internal tables, intermediate calculation results, and the like.
The Lifecycle Management Context Services 322 may provide the infrastructure for accessing the runtime context of the technical infrastructure. The system::get_diagnostics core service may be called by the service manager 316 within the user's context to provide diagnostic data from the technical layers in the infrastructure (chapter 4.3.2.4). In some variations, Lifecycle Management Context Services 322 automatically detects all the technical components that have been active during a transaction (e.g. by analyzing the statistical records).
As stated above, the secondary support context persistence is written by the service manager 316 (at 6) to a second database channel. Thus, it is possible to commit the data on the database 324, without having to commit on the original applications. This arrangement enables the saving of the diagnostic context without having to save the applications, which might undesirable, or impossible due to an inconsistent state of the application, and triggering of several support requests at various stages of the work within a single application transaction. An additional advantage of the secondary support context persistence is, that experts can access the diagnostic data using low level tools, even when there are massive problems in the infrastructure that would inhibit normal processing (e.g. object based navigation, or the asynchronous B2B interface which is used to transport the data from the support context business object to the service request in backend 2306).
The Support Context Business Object 328 is a business object, which is modeled within ESI. It contains all the diagnostic data that is created from the system and application context, when the support process is started. It contains the following: data that can be entered by the end user within the Request Support UI 326; diagnostic data, that is always present (such as generic data from the frontend context, or the ESI layer, or the system layer); data that depends on the business objects that have been in memory; and data that depends on the technical components that have been used (e.g. the IPC, TREX, etc.). Thus, data of such components is only contained in the Support Context Business Object 328, when the respective component has been used.
The Service Request Business Object 344 is a business object that is modeled within the Application Platform. It encapsulates information needed for incident management. The diagnostic data is stored together with the service request in a container, and can be used for inspection, solution search and wizards there.
The context data (also referred to as diagnostic data) may be obtained from the various layers of the architecture of the customer system 208. As stated above, the provision of context data allows for a proper reference for the identified incident and for a structured manner of analyzing the cause of the incident and for determining an appropriate way to resolve the incident.
With reference to
The context data as used herein may include relevant system and business information from one or more architectural layers: UI layer 402, ESI Service layer 404, BO layer 406 and Application Server 408. The gathered information must support at least one of one of the following use cases: solution search (known error identification/assignment) and wizard's execution (analysis wizards), inspection (error cause identification) with the ability to simulate error situation.
Relevant information may be defined on a layer-by-layer basis and can generally relate to (a) generic data provided by the infrastructure (e.g. statistical records) or a message log; or (b) components specific data defined by each component individually with respect to understanding an error situation and performing error cause identification and resolution thereto (this component specific data is especially relevant for the BO Layer 406).
The UI Layer 402 may consist of the Frontend Runtime 314 which in turn includes a Portal Runtime 414 (in which various portal services 418 such as user management, portal content directory, and object link service may reside) and a Web Dynpro runtime 416. The UI layer of applications may implemented, for example, using Java. Relevant context data obtained from this layer may include, for example, user data, work center and role definition as well as displayed fields with input data/content.
The UI Layer 402 may obtain data such as a user ID of the end user (e.g., the person creating the incident message). A session ID may also be obtained to determine the session from which the support request has been initiated; a Web Dynpro pattern and floor plan from which the call has been sent. Additionally, a portal role to which the enduser has been assigned may be obtained. This role may be pertinent to the authorizations, worksets the user can see, and the layout of the pages in the portal.
The UI Layer 402 may also obtain information characterizing a work set the end user is currently working in to enable an identification of a screen which is being presented to the end user when initiating the incident message. Some worksets may additionally comprise notes which may be obtained and form part of the context data.
Additional information that may be obtained by the UI Layer 402 include a locale parameter characterizing the browser utilized by the end user, the language the user is logged on, local time, and the like; an application ID of the application UI component(s) that are visible as part of the work set. Furthermore, the context data from the UI layer 402 may provide an intelligent screenshot that contains data that was presented to the end user at the time the incident message was initiated. By providing such information (which may comprise, in some variations, a screenshot of the entire screen/window being presented to the initiating and/or an identification of omitted fields, etc.), a support user may be provided with sufficient data to reproduce the problem, etc.
The ESI Layer 404 may include the service manager 316 and additionally a message handler 422, where internal and external error messages from the application are stored for a certain session. The ESL Layer 404 may also optionally include a central extensibility repository 420. Relevant context data obtained from the ESI Layer 404, includes, for example, registered/called services or process steps in the BO Layer 406.
In ESI Layer 404 all metadata of Business Objects is stored (in terms of process flow, called service, etc.). Therefore the ESI Layer 404 may deliver all generic (as opposed to application component specific) information. This generic information may include all registered services that are called throughout the session by help of the service manager 316. Thereby the service manager 316 collects information about registered services or buffer data from ESI layer 404 as well as all ESI framework information, that is retrieved by the service manager 316 itself. Other context data that may be obtained from the ESI layer 404 includes traces of data flow for the service interface, and data characterizing transient messages in the message handler 422.
The BO Layer 406 is the software layer in which the business objects 426 (and additionally configuration objects 424) are implemented, using, for example, ABAP coding. Relevant context data obtained from the BO Layer 406 include, for example, configuration data or transaction data.
Context data derived from the BO Layer 406 may include called business object(s) which are clearly identified by business object type (e.g., PurchaseOrder) and business object ID. Additional, characteristics of business objects, such as its respective configuration data, may be obtained for the context data. Other characteristics may relate to how a particular business object may be and is used. For example, in the area of “determination”, a list of potential determinations in the system, which of these determinations have been activated and how they have been or will be used may also be utilized.
Information regarding available extensions (e.g., including their configurations) may also be obtained from the BO Layer 406; as well as information relating to a system expectation regarding a field value. For example, the system knowing what type of data it expects, therefore can determine valid values that can be entered into a field. Thus, the system has to be able to assess whether or not the entered field value is a valid one or not and should display this accordingly.
Called methods and performed action information may be used to generate the context data. In the BO layer 406, in some variations, only the actual used implemented method of core service operations and the actual performed action is needed. The context data may also comprise data characterizing a trace, recording the actual performed “action” from the beginning of the session upon the time the error occurs is relevant.
Moreover, the context data obtained from the BO layer 406 may include information relating to an affected business object including information about all its business objects nodes (e.g., all elements of such business object which points to a node in the associated data model). With this information, each node can be identified by a key and contains a fix amount of attributes. In addition, information about the associations of the business objects (e.g., directed relationships between business object nodes). Services for navigation on top of the nodes are assigned to the association (which may be a composition or an aggregation association).
Context data may also include BO data as of the time the error/incident occurred. Checkpoint data at critical places in program coding can be used to provide context data that characterizes an internal status of the program (and which may, for example, be written to a log). Rules may be pre-defined which determine when to classify a situation as critical and what related data to populate in the log.
The Application Server 408 refers to the technical layers of the infrastructure, such as the SAP Web Application Server, J2EE engine, TREX, LiveCache, Portal Infrastructure, BI, XI, JTS, Database Interface, and the like. The Application Server 408 may comprise a central monitoring system 428 for monitoring various operating parameters of applications and for storing such parameters as statistical records 430. Moreover, the Application Server 408 may include a message log 432 that records messages relating to business object 426 and message buffer 434. Relevant context data from the Application Server 408 include, for example, statistical records or system information such as software release and patch level.
The Application Server 408 may provide a transaction ID of the entire transaction throughout the solution (i.e., through all of the technology stacks) so that statistical records 430 may be generated. The statistical records 430 may characterize remote function calls to other components; database accesses; CPU usage; memory usage; data transfer to and from the database 324, database 324 response time, and the like. The context data may also utilize information regarding the agents called from the beginning of a session upon the time the error occurs and the “runtime” of each of these agents (which may be provided by a trace).
Operating system, software release version, patch level and implemented SAPNotes information may also form part of the context data. Such information may be used for both, identifying which bugs already have been fixed and upon which software version error corrections can be applied. Relevant information is gained from the system landscape directory (SLD) and can also be readout via the statistical records.
With reference to
Activation of an incident message in the worklist 602 may cause an expanded view 700 (see
As soon as an incident message has arrived in the service desk system, it must be processed as efficiently and effectively as possible. Thus the manual steps occurring usually within a service desk system (such as identifying the right processor, classification, prioritization, escalation handling based on service level agreements, etc.) should be automated using a rules engine based on the information that can be provided with the context data. For example, based on the categorization within the context data (e.g. the information “problem has occurred in the SRM application”), an automatic identification of the right service desk employee or key user can be performed (e.g. the “purchasing key user”). In some variations, a database administrator subscribes to all incidents that are caused by database errors. Therefore, the context data must provide enough information to test for the condition “this incident is caused by a database error”. This association can be accomplished, for example, by a classification of error messages.
As soon as an incident has been assigned to the key user, and he/she starts to work on the incident, he/she would like to get a quick overview on the situation in which the incident has occurred. By providing the context data to the key user, unnecessary communication between the end user and the key user are avoided thereby reducing an amount of time required to resolve the support issue. In order to allow the key user to understand the context data, it must be presented in human-readable format. This presentation allows for a user to determine, among other things, where did the error occur? (i.e., which screen the end user has been working on); which data has been entered? (i.e., business document number); what was the reaction of the system? (e.g. error messages displayed) and the like.
The key user may quickly identify one or more reasons which caused the error (which in turn caused the end user to generate the incident message). For example, user handling errors often can be spotted immediately by examining the data entered by the end user (e.g., wrong material numbers or space in the wrong places). These are all actions which are straightforward for a human user, but which are difficult to implement absent an exhaustive rule engine.
The key user may also support the end user in understanding error messages and proposing appropriate reactions to resolve the error. Again, an experienced key user that understands the meanings of various message can quickly provide recommendations to the end-user based on the text of the error messages.
In order to address UI issues, the key user may be provided with information (e.g., screenshots) which show what the end user has been seeing on his/her screen. By providing this information in the incident message, the key user does not need to access the computing system using the ID of the end user who might have a different set of authorizations and personalization settings ( e.g. fields for the end user are missing on the screen because of a wrong configuration setting) than the key user. In other situations, the key user may require the business object type and business object number to analyze data that is stored in the system to resolve the incident.
In some variations, the context data may be used to conduct an automatic search in a solution database (e.g., SAP Notes, local solution database, or remote solution database at a partner or available online) which may be populated, in part, with solutions to previously generated incident messages. In order to effect such a search, attributes within the context data must be matched or otherwise mapped to attributes in the applicable solution database. Example attributes include the SAP component, that allows to restrict the search within the solution database, error numbers, program names, field identifiers from the UI and the like. Therefore, only those solutions having matching attributes may be presented to the key user for selection and implementation. If there is only one identified matching solution, it may, in some variations, be implemented automatically.
The context data may also be used to filter out available analysis and correction wizards and tools, that are offered to the key user within the service desk for analyzing or resolving the error. For example, if the functionality “price determination” has been executed within the incidents context, a pricing analysis wizard may be offered to the processor of the incident because the problem might be related to pricing.
Moreover, once a wizard or tool has been selected by the key user, it requires data that it can process. As the key user (or support staff) is working in a different environment than the end user who created the incident, the diagnostic data stored with the incident must be comprehensive enough for the wizards. Thus, a (time consuming and error prone) logon to the customer's system for reproduction of the error can be avoided in many cases. In some cases, interrogatories presented by the wizard may be pre-populated with field values or have pre-selected graphical user interface elements based on the context data. Additionally or in the alternative, one or more of the interrogatories in the wizard may be omitted if the context data can be used to address the problem/step described in one of the interrogatories.
In many cases, the incident is related to errors in the business configuration (e.g., wrong pricing procedure, or route determination). Therefore the context data must contain the relevant data from the business configuration, that allow application consultants (or support experts) to analyze the configuration settings the system has used at the time of the incident, without having to logon to the system.
Various implementations of the subject matter described herein may be realized in digital electronic circuitry, integrated circuitry, specially designed ASICs (application specific integrated circuits), computer hardware, firmware, software, and/or combinations thereof. These various implementations may include implementation in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.
These computer programs (also known as programs, software, software applications or code) include machine instructions for a programmable processor, and may be implemented in a high-level procedural and/or object-oriented programming language, and/or in assembly/machine language. As used herein, the term “machine-readable medium” refers to any computer program product, apparatus and/or device (e.g., magnetic discs, optical disks, memory, Programmable Logic Devices (PLDs)) used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term “machine-readable signal” refers to any signal used to provide machine instructions and/or data to a programmable processor.
To provide for interaction with a user, the subject matter described herein may be implemented on a computer having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user and a keyboard and a pointing device (e.g., a mouse or a trackball) by which the user may provide input to the computer. Other kinds of devices may be used to provide for interaction with a user as well; for example, feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form, including acoustic, speech, or tactile input.
The subject matter described herein may be implemented in a computing system that includes a back-end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front-end component (e.g., a client computer having a graphical user interface or a Web browser through which a user may interact with an implementation of the subject matter described herein), or any combination of such back-end, middleware, or front-end components. The components of the system may be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network (“LAN”), a wide area network (“WAN”), and the Internet.
The computing system may include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.
Although a few variations have been described in detail above, other modifications are possible. For example, the logic flow depicted in the accompanying figures and described herein do not require the particular order shown, or sequential order, to achieve desirable results. Other embodiments may be within the scope of the following claims.
