FIELD OF THE INVENTIONThe present invention generally relates to data processing. More particularly, the present invention relates to systems and methods for providing context-dependent value help information for business objects.
BACKGROUND OF THE INVENTIONThere is, and will continue to be, advances and changes in how enterprises conduct business. Whether these advances and changes occur through growing competition and globalization, mergers and acquisition, or a revamping of business models, the key for success will often depend on how quickly the enterprise's information technology (IT) organization can adapt to evolving business needs. Therefore, a major challenge to these enterprises is how they handle change.
For organizations to enable business agility, they must ensure that enterprise applications are not only high-performance business engines driving efficiencies, but also that they become flexible building blocks of future business systems. A recent promising solution has risen in the form of services. A service, such as a Web service or other program accessible through a network, represents a self-contained, self-describing piece of application functionality that can be found and accessed by other applications. A service may be considered self-contained because the application using the service does not have to depend on anything other than the service itself, and self-describing because all the information on how to use the service can be obtained from the service itself. The descriptions are centrally stored and accessible through standard mechanisms.
Instead of requiring programmers to establish and maintain links between applications, services are loosely coupled, making connections simpler and more flexible and allowing application architects to more easily find and understand services offered by other cooperative applications. However, the problem that exists with services is that they are often designed to expose functionality of individual applications and thus are too limited to be efficient building blocks for enterprise-wide business processes. A solution to this shortfall has been the migration to a Service Oriented Architecture (SOA). The SOA is an open architecture middleware, which builds on the benefits of services. An example of an SOA can be found in the Enterprise Service Framework (ESF), which is commercially available from SAP AG, Walldorf, Germany. The term “SOA” may also be used to refer to “distributed objects” architecture, such as CORBA (Common Object Request Broker Architecture) and DCOM (Distributed Component Object Model).
The SOA enables the abstraction of business objects (BO), modeled as services (also referred to as enterprise services), from actual applications. Aggregating services into business-level enterprise services may provide more meaningful building blocks for the task of automating enterprise-scale business scenarios. Enterprise services allow IT organizations to efficiently develop composite applications, defined as applications that compose functionality and information from existing systems to support new business processes or scenarios.
The SOA also enables the use of an enterprise services repository. The enterprise services repository stores relevant pre-existing enterprise services and makes them available to selected partners and customers. By using the enterprise services repository, these selected partners and customers can use the pre-existing enterprise services to aid in the implementation of new services and corresponding business objects. The term business object (BO) represents a data structure, such as an object having significance to a business (e.g. a business object for providing a purchase order). An “object” refers to a software bundle of variables (e.g., data) and related methods. For example, in object-oriented programming, an object is a concrete realization (instance) of a class that consists of data and the operations associated with that data.
When services and business objects are developed, the fields which may be filled in with values at the user interface may be defined within the business object and may be fixed for the lifetime of the application providing the business object. For example, a business object for a purchase order may have a field for the purchase order id and a field for the date. If these fields need to be updated or changed, each business object that contains the values must be updated as well. As such, there is a need to improve development of business objects and their corresponding values.
SUMMARY OF THE INVENTIONThe present invention provides methods and apparatus, including computer program products, for generating context-dependent value help information.
In one exemplary embodiment, there is provided a method for providing context-dependent value help information. The method may include receiving a call at a first service provider to instantiate a first business object. The method may also include calling a second service provider when the first service provider determines that a context-dependent value help information is required. Moreover, the method may include receiving a call at the second service provider to instantiate a second business object to determine the context-dependent value help information. The method may further include calling, by the second service provider, the first service provider to provide the determined the context-dependent value help information. The method may also include receiving, at the first service provider, the determined context-dependent value help information.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as described. Further features and/or variations may be provided in addition to those set forth herein. For example, the present invention may be directed to various combinations and subcombinations of the disclosed features and/or combinations and subcombinations of several further features disclosed below in the detailed description.
BRIEF DESCRIPTION OF THE DRAWINGSThe accompanying drawings, which are incorporated in and constitute a part of this specification, show certain aspects of the present invention and, together with the description, help explain some of the principles associated with the invention. In the drawings,
FIG. 1 illustrates a block diagram of an exemplary system environment consistent with certain aspects related to the present invention;
FIG. 2 illustrates an exemplary schema consistent with certain aspects related to the present invention;
FIG. 3 illustrates a flow chart with exemplary steps for generating objects consistent with certain aspects related to the present invention; and
FIG. 4 illustrates a screenshot of a user interface with a pull down window showing context-dependent value help information consistent with certain embodiments of the present invention.
DESCRIPTION OF THE EMBODIMENTSReference will now be made in detail to the invention, examples of which are illustrated in the accompanying drawings. The implementations set forth in the following description do not represent all implementations consistent with the claimed invention. Instead, they are merely some examples consistent with certain aspects related to the invention. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts.
FIG. 1 is a block diagram of anexemplary system100 environment that includes aclient system110 and aserver system130 for generating business objects.Client system110 includes a user interface (UI)120.Client system110 connects toserver system130 throughnetwork connection150a.Server system130 further includes service manager (SM)140,service provider160, a context-dependent service provider161, andrepositories171 and172.System100 may be implemented as part of an enterprise services framework (ESF). An enterprise services framework is a type of computer framework, such as a client-server architectural framework, that includes one or more services, such asservice providers160 and161. The services are accessible to other parts of the ESF, such as client systems and their corresponding users, through a communication mechanism such as the Internet or an intranet. The ESF may be constructed using tools provided by SAP Netweaver™ (commercially available from SAP AG, Walldorf, Germany). AlthoughFIG. 1 shows asingle client system110 and asingle server system130, a plurality of client systems and server systems may be used. Moreover, the components depicted inFIG. 1 may be distributed among multiple locations. AlthoughFIG. 1 is described with respect to a client-server architecture and an ESF,system100 can also use any other architecture or framework.
Client system110 may include one or more processors, such as computers, to interface withserver system130. User interface120 may provide an interface to allow a user to interact, throughservice manager140, with other applications, such as service providers160-161 and their corresponding business objects stored in repositories171-172. Moreover, a service, such asservice160 may call another service, such as context-dependent service provider161 to obtain context dependent value help. Value help information may be information, such as values, to help a user perform a task (e.g. complete a purchase order). This value help information may be provided based on context, such as the context of information provided by the user or the context of the service. For example, if the user inputs Germany (“GE”) as the destination country for the purchase order, a context-dependent service provider161 may be called to provide context-dependent value help information. In this example, the context-dependent service provider161 returns, for the context “GE,” a complete list of the regions (also referred to as provinces) associated with the country code “GE” determined at runtime.
Moreover, another service provider (not shown) may also call context-dependent service provider161 to obtain context-dependent value help. For example, a service provider may generate shipping documents for a user at user interface120. In this example, the service provider may receive an input from a user that the destination country for the shipping documents is GE, enabling the service provider to call context-dependent service provider161 with the context “GE.” The context-dependent service provider161 responds by calling the shipping documents service provider to provide the value help information (e.g. regions in a Germany), which allows the shipping documents service provider to generate value help information for display at user interface120. Accordingly, context-dependent service provider161 provides a service that provides value help information to other services or applications—reducing and/or eliminating the need for each of these other services to include their own dedicated value help information.
A user may be any type of user, such as a system designer, a software developer, and/or a processor. User interface120 may include a browser to provide content from service providers160-161. In some implementations, SAP Web Dynpro (commercially available from SAP AG, Walldorf, Germany) is used as a model-based development environment for generating user interface120, although other development environments can also be used.
Network connections150a-150emay include, alone or in any suitable combination, a telephony-based network, a local area network (LAN), a wide area network (WAN), a dedicated intranet, wireless LAN, the Internet, an intranet, a wireless network, a bus, or any other communication mechanisms. Further, any suitable combination of wired and/or wireless components and systems may provide network connections150a-150e. Moreover, network connections150a-150emay be embodied using bi-directional, unidirectional, or dedicated communication links. Network connections150a-150emay also implement standard transmission protocols, such as Transmission Control Protocol/Internet Protocol (TCP/IP), Hyper Text Transfer Protocol (HTTP), SOAP, RPC, or other protocols.
Server system130 may include one or more processors, such as computers, to interface with other computers, such asclient system110.Client system110 may callservice manager140 atserver130. Althoughservice manager140, service providers160-161, and repositories171-172 are depicted withinserver130, they can each be located anywhere and distributed among multiple locations.
Moreover, whenservice manager140 is called by user interface120,service manager140 may call a procedure to instantiateservice provider160. As used herein, the term “instantiate” means, in an object oriented programming environment, an object of a particular class, and, more generally, includes deploying, customizing, running and/or executing an application.Service provider160 may be implemented as a service which may be called byservice manager140. An example of a service is a Web service, although any other type of application accessible through a network may be used. Whenservice provider160 is instantiated byservice manager140,service provider160 may also instantiate one or more corresponding business objects. For example, a user of user interface120 may accessservice provider160 to interact with a product catalog or sales order. The data and methods associated with providing the product catalog or sales order to user interface120 correspond to a business object. A business object may also include a business object node, which refers to a portion of the business object. In some instances, a business object may be implemented as a data structure including methods and/or procedures associated with that data. Returning to the above product catalog example, a business object node may refer to another object, such as a price or a product description, included within the business object. Business objects and nodes may be stored in a repository, such asrepositories171 or172.
Repositories171-172 may be implemented as a storage device for storing information associated with business objects including their metadata. Repositories171-172 may store information associated with the business objects (e.g., the data and methods associated with the product catalog or sales order) including metadata for the business objects. For example, repositories171-172 may store a list of business object nodes including an identifier (ID) and data content. The ID of a business object refers to an identifying memory address of a business object node that uniquely identifies individual business object nodes within repositories171-172. The memory address can be used to access and read data content of a particular business object node. For example, an ID of a business object node may consist of a directory structure and filename associated with the business object node. Repositories171-172 may be implemented as an enterprise services repository, although any other computer-readable storage medium may be used.
Repositories171-172 may also store metadata regarding one or more business objects. Metadata may be defined as data about data. For example, metadata may refer to information about the data itself, such as content, quality, condition, origin, size, formatting, characteristics of data, and the like. The eXtensible Markup Language (XML) is a specific example of metadata because it is a format used to define other data objects. Metadata may include a schema. A schema is the organization or structure, such as the organization of a database or the structure of an object in an object oriented program. In object oriented programming, modeling (i.e., the analysis of objects that are used in a business or other context and the identification of the relationships among these data objects) leads to a schema, which can be stored in repositories171-172 as a schema. The schema can be depicted visually as a structure or a formal text-oriented description (e.g., script). For example, metadata may be in the form of database tables. The metadata may include information such as the number of nodes in a business object, the name(s) of the nodes, the position of a node in the business object hierarchy, the structure of a node, associations, actions, and default queries on a node. An exemplary XML data schema is further described below in relation toFIG. 2.
FIG. 2 depicts an example schema for business object nodes containing data stored atrepository171 and172. During design time, the business objects are designed (or modeled), and at runtime the business objects are instantiated so that a user may interact (e.g. view, fill-ins, store, and the like) with an “instance” of the business object. The schema includes a business object node for asales order201a, thesales order items201bincluded withsales order201a, the correspondingproduct description201c, and thedestination address201dfor the products. Moreover, the schema depicted inFIG. 2 may include keys201a-201cthat identify the relationships among the business object nodes201a-201d. For example, key202ais a sales order identification value (“id”) that is used to linkbusiness object nodes201aand201b.Key202blinks the product identification values (“product id”) ofsales order items201bto the product description values ofproduct description201c.Key202clinks the product description values of the sale order to thedestination address201d.
The schema, which depicts business object nodes and how they are associated to one another, may be considered metadata and stored in a repository, such asrepository171. Moreover, the schema may be considered a “model” of how to implement these business object nodes. The model may serve as a template to enable the composition of other models for business objects and their nodes. The models may also be used to generate script for generating code for the business objects and their nodes. The schema may be stored as metadata inrepository171. During the final implementation ofsystem100, a user would interact (e.g. view, fill-ins, store, and the like) with a service provider to access the business objects (e.g. business objects for a purchase order) stored at therepository171.
At runtime, the destination addressbusiness object node201dmay prompt the user to provide an address. Runtime refers to any time other than when business objects inrepositories171 and172 are being designed. One of the fields for the destination address that the user may enter is the country code (e.g. GE, USA, GB, etc.).Destination address node201ddepicts the field for the country code as “customer_country”220. Based on the country code that the user inputs, the destinationaddress business object201dmay determine that context-dependent value help information should be determined by making a call to context-dependent service provider222. Value help information may be information, such as values, to help a user perform a task (e.g. complete a purchase order). This value help information may be provided based on the context of the information from the user. For example, if the user inputs Germany (“GE”) as the destination country for the purchase order, context-dependent value help information may provide provinces associated with the context of country code (e.g. Germany or GE) determined at runtime. Once the destination addressbusiness object node201ddetermines that a call to the context-dependent service provider161 is required, the destination address business object node198dmay call the context-dependent service provider161 by, for example, sending a Simple Object Access Protocol (SOAP) message or making a Remote Procedure Call to context-dependent service provider161.
Once the destination addressbusiness object node201dcalls the context-dependent service provider161, the context-dependent service provider161 receives the call. The call to context-dependent service provider161 may include information identifying the context of the call. In this case, the call would include runtime information, such as country code GE. Once the call is received, the context-dependent service provider161 may instantiate one or more corresponding business object nodes that may be stored inrepository172.
FIG. 2 further depictsbusiness object node201efor the context of country code andbusiness object node201ffor the region or province code corresponding to the country code that was provided byservice160. These business object nodes are stored inrepository172.Key202dis a region or province code identification value (“country id”) that is used to link thecountry code201eand regions orprovinces201f. For example, if the user inputs Germany (“GE”) as the destination country in thebusiness object node201dfor the destination address, the user may also need to select the corresponding region or province in Germany. However,business object node201dmay not have information associated with the provinces in Germany, and may not be able to provide a list of provinces to the user. Therefore,business object node201dmay need value help information that is dependent on the context of the country (e.g. Germany). If value help information is needed, destination addressbusiness object node201dcalls the context-dependent service provider161, and the context-dependent service provider161 may receive the call, including information identifying the context of the call (e.g. a country code “GE”). Context-dependent service provider161 may instantiate the business object node for thecountry code201efor Germany (“GE”). Once this business object is instantiated, the business object may generate a list that may include only the provinces that correspond to the country Germany (“GE”).
Once the context-dependent service provider161 determines the list of province codes associated with the context, in this case the country code GE (i.e. Germany), theservice provider160 may receive the context-dependent value help information from the context-dependent service provider161. Once theservice provider160 receives this context-dependent value help information, theservice provider160 may instantiate any additional business objects to incorporate the received context-dependent value help information.
FIG. 3 is a flowchart of exemplary steps for generating context-dependent value help information. At runtime, thefirst service provider160 receives a call, such as a SOAP message, Remote Procedure Call (RPC), or any other type of call, from theservice manager140 to instantiate a business object atstep310. Theservice provider160 may instantiate one or more business objects inrepository171. For example, the one or more business objects may include asales order201a,sales order items201b,product descriptions201c, and theuser destination address201d. During runtime, the user may select the items and complete a sales order by entering a destination address. When the user enters the destination country, destination address business object198dmay determine that context-dependent value help information is required. For example, when a user inputs “GE,” value help in the form of a list of provinces may be required. The value help information is dependent on the context, which in this example is “GE.” If context-dependent value help information is required, the destination address business object198dmay call the context-dependent service provider161 atstep320. The call may provide the “context.” For example, when a user enters Germany (“GE”) as the desired country in the business object node for thedestination address201d, the destination addressbusiness object node201dmay call the context-dependent service provider161 which provides a list of the corresponding provinces based on the context.
Once the call is received at context-dependent service provider161, context-dependent service provider161 may instantiate the business object nodes for thecountry code201efor Germany and corresponding regions orprovince codes201f(e.g. Baden-Württemberg, Bayern, Berlin, Brandenburg, Bremen, Hamburg, Hessen, Mecklenburg-Vorpommern, Niedersachsen, Nordrhein-Westfalen, Rheinland-Pfalz, Saarland, Sachsen, Sachsen-Anhalt, Schleswig-Holstein, and Thüringen) atstep330. Once the province list is generated bybusiness object node201f, context-dependent service provider161 may callservice provider160 to provide the context-dependent information, such as the list of provinces that correspond to the country code Germany atstep340. This call may include the original context, such as “GE,” and the corresponding provinces. Theservice provider160 may receive the call from the context-dependent service provider161 atstep350. Finally, theservice provider160 may incorporate the list of provinces associated the country code Germany atstep360. Once this list is incorporated, the user may be presented with a list of the provinces corresponding to Germany, and the user may select the desired province as part of the destination address.
In this example, the list of provinces depend on the country code that may be entered by the user. Based on the “context” of the country code (e.g. “Germany”), theservice provider160 may receive the call from the context-dependent service provider161 that includes the list of provinces that correspond to the country code Germany. The above example of context-dependent service provider161 providing context-dependent value help is only exemplary sinceservice provider161 may provide any other context-dependent value help information. For example, based on the context of “destination address,” context-dependent service provider161 may provide a sales order item that contains only the products that can be shipped to that destination address. For example, if the context of “destination address” is only accessible by air, then flammable materials may not be listed in the value help provided by context-dependent service provider161 toservice provider160 for a sales order. Also, there may be a set quantity of each product that the user may purchase based on the destination address. Context-dependent value help information may thus be used to determine the type of product that may be ordered and the quantity of each product. Moreover, although the context may based on information provided by a user at runtime, any other context may be used. For example, the state or status of theservice160 may be used to determine the context for which value help information should be determined.
FIG. 4 depicts auser interface400 where a sales order form can be viewed, and modified using a user interface, such as a Java Applet window, although other graphical user interfaces may be used as well.
At runtime, user interface120 callsservice manager140.Service manager140 may call a procedure to instantiateservice provider160. Whenservice provider160 is instantiated,service provider160 may also instantiate one more business objects for a sales order. The business objects, which include business object nodes, may be stored inrepository171. For example, business object nodes may exist for asales order201a, thesales order items201bincluded withsales order201a, and thecorresponding product description201c. The user may then select one ormore products402 as sales order items. Thebusiness object node201cfor the corresponding product description may display theproduct description404, and the user may select a desiredquantity406 of the product. The destination addressbusiness object node201dmay display entry fields for the user to enter auser name408, adestination street address410, and adestination country412.FIG. 4 depicts aproduct402 of filter, aproduct description404 of 16″×20″, and a product quantity of 12.FIG. 4 also depicts the user providing adestination country412 of Germany.
When the user enters thedestination country412, destinationaddress business object201dmay determine that context-dependent value help information should be determined. Once the destination addressbusiness object node201ddetermines that a call to the context-dependent service provider161 is required (See, e.g.,FIG. 2 at222), the destination address business object node198dmay call the context-dependent service provider161. Once the call is received, the context-dependent service provider161 may instantiate one or more corresponding business object nodes that may be stored inrepository172, such asbusiness object node201efor the country code andbusiness object node201ffor the province code corresponding to the country code that was input. The call to context-dependent service provider161 may include information identifying the context of the call (e.g. country code is “GE”). Context-dependent service provider161 may instantiate the business object node for thecountry code201efor Germany (“GE”). Once this business object is instantiated, the business object may generate a list that may include only the provinces that correspond to the country Germany (“GE”).
Once the context-dependent service provider161 determines the list of province codes associated with the context, in this case the country code GE (i.e. Germany), theservice provider160 may receive the context-dependent value help information from the context-dependent service provider161. When theservice provider160 receives this context-dependent value help information, theservice provider160 may instantiate any additional business objects to incorporate the received context-dependent value help information. Once the additional business objects are instantiated, a list of provinces inGermany414 may be provided to user interface120 for display so that the user may select the appropriate province for the destination address.FIG. 4 also depicts the provided valuehelp province information414.
The foregoing description is intended to illustrate but not to limit the scope of the invention, which is defined by the scope of the appended claims. Other embodiments are within the scope of the following claims.