Patent Application
20080263006
This invention relates to data processing and, more particularly, to systems and software implementing a search that concurrently searches heterogeneous data comprising structured and unstructured data.
Advances in electronic storage technology have made feasible the storage of vast amounts of this information as ever-larger storage capacity devices are introduced. In particular, as electronic storage densities increase and the cost of electronic storage decreases, businesses are eagerly adopting comprehensive electronic storage procedures for storing their business information. Additionally, the proliferation and widespread acceptance of electronic business transactions and communications has fueled significant demand for voluminous electronic storage capacity. Typically, businesses will store electronic information in storage devices, often referred to as data repositories or data stores. Databases of electronic information may be maintained in the data repositories, and the information may be organized as a series of objects, each object including one or more attributes that may take values.
Specifically, many computer systems include repositories or other storage facilities for holding structured data (such as database records or business objects) and unstructured data (such as files, attachments, and such). The systems typically provide some search functionality for a user to identify the particular item that the user is interested in. For example, a customer relationship management (CRM) solution may offer many different types of business objects to a system user (e.g., account data, running marketing plans, and so forth). There may be many object instances stored in the repository for each object type. Indeed, some systems include items of several different types, where each item type is managed by a separate application program. Moreover, different repositories or storage devices may be used to store unstructured data.
The present disclosure relates to methods, systems, and software for querying heterogeneous business data comprising structured data and unstructured data. In one general aspect, structured data may include business objects stored in structured repositories. Each repository may store several business objects, each business object associated with one or more nodes. Unstructured data can include attachments, each of which can be associated with a business object node. The results from an unstructured repository can be used to identify further results in a structured repository. The structured data and unstructured data may be stored across one or more repositories.
For example, a computer implemented method receives a query for the heterogeneous business data and automatically parses the received query into sub-queries. Each sub-query can be associated with either structured or unstructured data stored in one of the repositories. At least one of the sub-queries can include a portion of the received query. The results of the various sub-queries can be merged automatically using business logic. In some cases, unstructured repositories can be searched based on a textual search of the unstructured data, or unstructured repositories can also be searched based on an attribute search of the unstructured data. Results from structured and unstructured repositories can be automatically merged utilizing union and intersection operations.
Moreover, some or all of these aspects may be further included in respective systems or other devices for executing, implementing, or otherwise supporting concurrent searches of structured and unstructured data. For example, software operable to search structured and unstructured repositories can include a query splitter software module and a result merger software module. The software modules can operate a service that is logically coupled to at least one search provider. The details of these and other aspects and embodiments of the disclosure are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the various embodiments will be apparent from the description and drawings, as well as from the claims.
The present disclosure relates to methods, systems, and software for the combination of attachment searches and relatively fast searches to allow the user to search through unstructured and structured data, respectively. The search requester may also query attributes associated with such attachments. For example, the disclosure describes example components and techniques for intelligently parsing a query into sub-queries based on relevance and then intelligently combining the results beyond mere aggregation. Specifically,
System 100 is typically a distributed client/server system that spans one or more networks such as 112. In such cases, the various components—such as servers 102 and clients 104—may communicate via a virtual private network (VPN), Secure Shell (SSH) tunnel, or other secure network connection. Accordingly, rather than being delivered as packaged software, system 100 may represent a hosted solution that may scale cost-effectively and help drive faster adoption. In this case, portions of the hosted solution may be developed by a first entity, while other components are developed by a second entity. In such embodiments, data may be communicated or stored in an encrypted format using any standard or proprietary encryption algorithm. This encrypted communication may be between the user (or application/client) and the host or amongst various components of the host. Put simply, communication or other transmission between any modules and/or components may include any encryption, export, translation or data massage, compression, and so forth as appropriate. Further, system 100 may store some data at a relatively central location, while concurrently maintaining local data at the user's site for redundancy and to allow processing during downtime. But system 100 may be in a dedicated enterprise environment—across a local area network (over LAN) or subnet—or any other suitable environment without departing from the scope of this disclosure.
Turning to the illustrated embodiment, system 100 includes or is communicably coupled (such as via a one-, bi-, or multi-directional link or network) with server 102 and one or more clients 104, at least some of which communicate across network 112. Server 102 comprises an electronic computing device operable to receive, transmit, process, and store data associated with system 100. Generally,
Illustrated server 102 includes local memory 120 and may be coupled to a repository 135. Memory 120 and repository 135 may include any memory or database module and may take the form of volatile or non-volatile memory including, without limitation, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), removable media, or any other suitable local or remote memory component. Illustrated memory 120 includes data services but may also include any other appropriate data such as VPN applications or services, firewall policies, a security or access log, print or other reporting files, HTML files or templates, data classes or object interfaces, child software applications or sub-systems, and others. Consequently, memory 120 and repository 135 may be considered a repository of data, such as a local data repository, for one or more applications.
For example, memory 120 may include, point to, reference, or otherwise store a business object repository. In some embodiments, the business object repository may be stored in one or more tables in a relational database described in terms of SQL statements or scripts. In the same or other embodiments, the business object repository may also be formatted, stored, or defined as various data structures in text files, eXtensible Markup Language (XML) documents, Virtual Storage Access Method (VSAM) files, flat files, Btrieve files, comma-separated-value (CSV) files, internal variables, or one or more libraries. In short, the business object repository may comprise one table or file or a plurality of tables or files stored on one computer or across a plurality of computers in any appropriate format. Indeed, some or all of the business object repository may be local or remote without departing from the scope of this disclosure and store any type of appropriate data. In particular embodiments, the business object repository may access the business objects in response to queries from clients 104.
These business objects 140 may represent organized data relating to some project or endeavor, which may or may not be linked, with each object having one or more states related to the object. Each of the states, in turn, is associated with data that pertains to various modifiable parameters of the individual states of the object. One type of data modeling that includes multiple objects, with each having multiple states and each state having multiple instances of changes to the state's modifiable parameters, is the business object model. Briefly, the overall structure of a business object model ensures the consistency of the interfaces that are derived from the business object model. The business object model defines the business-related concepts at a central location for a number of business transactions. In other words, it reflects the decisions made about modeling the business entities of the real world acting in business transactions across industries and business areas. The business object model is defined by the business objects 140 and their relationship to each other (the overall net structure).
Business object 140 is thus a capsule with an internal hierarchical structure, behavior offered by its operations, and integrity constraints. Business objects are generally semantically disjointed, i.e., the same business information is represented once. In some embodiments, the business objects are arranged in an ordering framework. From left to right, they are arranged according to their existence dependency to each other. For example, the customizing elements may be arranged on the left side of the business object model, the strategic elements may be arranged in the center of the business object model, and the operative elements may be arranged on the right side of the business object model. Similarly, the business objects 140 are generally arranged from the top to the bottom based on defined order of the business areas, e.g., finance could be arranged at the top of the business object model with CRM below finance and SRM below CRM. To ensure the consistency of interfaces, the business object model may be built using standardized data types as well as packages to group related elements together, and package templates and entity templates to specify the arrangement of packages and entities within the structure.
BO 140 is a representation of a business entity, such as an employee or a sales order. The BO 140 may encompass both functions (for example, in the form of methods) and data (such as one or more attributes) of the business entity. The implementation details of BO 140 are typically hidden from a non-development user, such as an end user, and the BO 140 may be accessed through defined functions. Accordingly, the BO may be considered encapsulated. BO may be used to reduce a system into smaller, disjunctive units. As a result, BOs can improve a system's structure while reducing system complexity. BOs also form a point of entry of the data and functions of a system and enable the system to easily share data, communicate, or otherwise operate with other systems. According to one implementation, BO 140 may include multiple layers.
Server 102 also includes processor 125. Processor 125 executes instructions and manipulates data to perform the operations of server 102 such as, for example, a central processing unit (CPU), a blade, an application specific integrated circuit (ASIC), or a field-programmable gate array (FPGA). Although
Other than BOs 140, system 100 may utilize various data services that can combine web services and data from multiple systems, in an application design made possible by a composite application framework. This framework typically includes the methodology, tools, and run-time environment to develop composite applications. It may provide a consistent object model and a rich user experience. Regardless of the particular type, category, or classification of the component, system 100 often stores metadata and other identifying information along with the actual piece of software (whether object or source). For example, the service may further include each component's definition, lifecycle history, dependents, dependencies, versions, use or “big name” cases, industry types or associations, role types, security profile, and usage information. More specifically, system 100 also includes (or otherwise references) unstructured data 142, generally described herein as attachments. Attachments 142 can include flat files, spreadsheets, graphical elements, design drawings, slide presentations, text documents, mail messages, or other files. In particular, if a combined search query is executed for business objects and attachments, the combined search query provider 165 can merge the result sets, such as lists of business objects matching the search query.
At a high level, business application 145 can be any application, program, module, process, or other software that may execute, change, delete, generate, or otherwise requests or implements batch processes according to the present disclosure. In certain cases, system 100 may implement a composite application 145. For example, portions of the composite application may be implemented as Enterprise Java Beans (EJBs) or design-time components may have the ability to generate run-time implementations into different platforms, such as J2EE (Java 2 Platform, Enterprise Edition), ABAP (Advanced Business Application Programming) objects, or Microsoft's .NET. Further, while illustrated as internal to server 102, one or more processes associated with application 145 may be stored, referenced, or executed remotely. For example, a portion of application 145 may be a web service that is remotely called, while another portion of application 145 may be an interface object bundled for processing at remote client 104. Moreover, application 145 may be a child or sub-module of another software module or enterprise application (not illustrated) without departing from the scope of this disclosure. Indeed, application 145 may be a hosted solution that allows multiple parties in different portions of the process to perform the respective processing. For example, client 104 may access application 145, once developed, on server 102 or even as a hosted application located over network 112, without departing from the scope of this disclosure. In another example, portions of software application 145 may be developed by the developer working directly at server 102, as well as remotely at client 104.
More specifically, business application 145 may be a composite application, or an application built on other applications, that includes an object access layer (OAL) and a service layer. In this example, application 145 may execute or provide a number of application services such as customer relationship management (CRM) systems, human resources management (HRM) systems, financial management (FM) systems, project management (PM) systems, knowledge management (KM) systems, and electronic file and mail systems. Such an object access layer is operable to exchange data with a plurality of enterprise base systems and to present the data to a composite application through a uniform interface. The example service layer is operable to provide services to the composite application. These layers may help composite application 145 to orchestrate a business process in synchronization with other existing processes (e.g., native processes of enterprise base systems) and leverage existing investments in the IT platform. Further, composite application 145 may run on a heterogeneous IT platform. In doing so, composite application 145 may be cross-functional in that it may drive business processes across different applications, technologies, and organizations. Accordingly, composite application 145 may drive end-to-end business processes across heterogeneous systems or sub-systems. Application 145 may also include or be coupled with a persistence layer and one or more application system connectors. Such application system connectors enable data exchange and integration with enterprise sub-systems and may include an Enterprise Connector (EC) interface, an Internet Communication Manager/Internet Communication Framework (ICM/ICF) interface, an Encapsulated PostScript (EPS) interface, and/or other interfaces that provide Remote Function Call (RFC) capability. It will be understood that while this example describes the composite application 145, it may instead be a standalone or (relatively) simple software program. Regardless, application 145 may also perform processing automatically, which may indicate that the appropriate processing is substantially performed by at least one component of system 100. It should be understood that this disclosure further contemplates any suitable administrator or other user interaction with application 145 or other components of system 100 without departing from its original scope. Finally, it will be understood that system 100 may utilize or be coupled with various instances of business applications 145. For example, client 104 may run a first business application 145 that is communicably coupled with a second business application 145. Each business application 145 may represent different solutions, versions, or modules available from one or a plurality of software providers or developed in-house. For example, business application 145 may include or be coupled with a combined search query provider 165. Various business applications 145 can use the combined search query provider 165, for example, to query business objects 140 (e.g., stored in a structured repository 141) and attachments 142 (e.g., stored in an unstructured repository 143). For instance, while searching the structured repository 141, the combined search query provider 165 can identify specific business objects 140 responsive to the query. Simultaneously, the combined search query provider 165 can search attachments 142 in the unstructured repository 143 for related information. This provider 165 could then intelligently Boolean the results such that appropriate items are presented, perhaps on a rolling basis, to avoid delays in response times.
Regardless of the particular implementation, “software” may include software and other computer implemental instructions, such as firmware, wired or programmed hardware, or any combination thereof, as appropriate. Indeed, each of the foregoing software applications may be written or described in any appropriate computer language including C, C++, Java, Visual Basic, assembler, Perl, any suitable version of 4GL, as well as others. It will be understood that while these applications are shown as a single multi-tasked module that implements the various features and functionality through various objects, methods, or other processes, each may instead be a distributed application with multiple sub-modules. Further, while illustrated as internal to server 102, one or more processes associated with these applications may be stored, referenced, or executed remotely. Moreover, each of these software applications may be a child or sub-module of another software module or enterprise application (not illustrated) without departing from the scope of this disclosure.
Server 102 may also include interface 117 for communicating with other computer systems, such as clients 104, over network 112 in a client-server or other distributed environment. In certain embodiments, server 102 receives data from internal or external senders through interface 117 for storage in memory 120, for storage in DB 135, and/or processing by processor 125. Generally, interface 117 comprises logic encoded in software and/or hardware in a suitable combination and operable to communicate with network 112. More specifically, interface 117 may comprise software supporting one or more communications protocols associated with communications network 112 or hardware operable to communicate physical signals.
Network 112 facilitates wireless or wireline communication between computer server 102 and any other local or remote computer, such as clients 104. Network 112 may be all or a portion of an enterprise or secured network. In another example, network 112 may be a VPN merely between server 102 and client 104 across wireline or wireless link. Such an example wireless link may be via 802.11a, 802.11b, 802.11g, 802.20, WiMax, and many others. While illustrated as a single or continuous network, network 112 may be logically divided into various sub-nets or virtual networks without departing from the scope of this disclosure, so long as at least portion of network 112 may facilitate communications between server 102 and at least one client 104. For example, server 102 may be communicably coupled to one or more “local” repositories through one sub-net while communicably coupled to a particular client 104 or “remote” repositories through another. In other words, network 112 encompasses any internal or external network, networks, sub-network, or combination thereof operable to facilitate communications between various computing components in system 100. Network 112 may communicate, for example, Internet Protocol (IP) packets, Frame Relay frames, Asynchronous Transfer Mode (ATM) cells, voice, video, data, and other suitable information between network addresses. Network 112 may include one or more local area networks (LANs), radio access networks (RANs), metropolitan area networks (MANs), wide area networks (WANs), all or a portion of the global computer network known as the Internet, and/or any other communication system or systems at one or more locations. In certain embodiments, network 112 may be a secure network associated with the enterprise and certain local or remote clients 104.
Client 104 is any computing device operable to connect or communicate with server 102 or network 112 using any communication link. For example, client 104 is intended to encompass a personal computer, touch screen terminal, workstation, network computer, kiosk, wireless data port, smart phone, personal data assistant (PDA), one or more processors within these or other devices, or any other suitable processing device. At a high level, each client 104 includes or executes at least one GUI 136 and comprises an electronic computing device operable to receive, transmit, process, and store any appropriate data associated with system 100. It will be understood that there may be any number of clients 104 communicably coupled to server 102. Further, “client 104,” “business,” “business analyst,” “end user,” and “user” may be used interchangeably as appropriate without departing from the scope of this disclosure. Moreover, for ease of illustration, each client 104 is described in terms of being used by one user. But this disclosure contemplates that many users may use one computer or that one user may use multiple computers. For example, client 104 may be a PDA operable to wirelessly connect with external or unsecured network. In another example, client 104 may comprise a laptop that includes an input device, such as a keypad, touch screen, mouse, or other device that can accept information, and an output device that conveys information associated with the operation of server 102 or clients 104, including digital data, visual information, or GUI 136. Both the input device and output device may include fixed or removable storage media such as a magnetic computer disk, CD-ROM, or other suitable media to both receive input from and provide output to users of clients 104 through the display, namely, the client portion of GUI or application interface 136.
GUI 136 comprises a graphical user interface operable to allow the user of client 104 to interface with at least a portion of system 100 for any suitable purpose, such as viewing application or other transaction data. Generally, GUI 136 provides the particular user with an efficient and user-friendly presentation of data provided by or communicated within system 100. For example, GUI 136 may present the user with the components and information that is relevant to their task, increase reuse of such components, and facilitate a sizable developer community around those components. GUI 136 may comprise a plurality of customizable frames or views having interactive fields, pull-down lists, and buttons operated by the user. For example, GUI 136 is operable to display certain data services in a user-friendly form based on the user context and the displayed data. In another example, GUI 136 is operable to display different levels and types of information involving data services based on the identified or supplied user role. GUI 136 may also present a plurality of portals or dashboards. For example, GUI 136 may display a portal that allows users to view, create, and manage historical and real-time reports including role-based reporting, and such. Of course, such reports may be in any appropriate output format including PDF, HTML, and printable text. Real-time dashboards often provide table and graph information on the current state of the data, which may be supplemented by data services. It should be understood that the term graphical user interface may be used in the singular or in the plural to describe one or more graphical user interfaces and each of the displays of a particular graphical user interface. Indeed, reference to GUI 136 may indicate a particular interface accessible via client 104, as appropriate, without departing from the scope of this disclosure. Therefore, GUI 136 contemplates any graphical user interface, such as a generic web browser or touchscreen, that processes information in system 100 and efficiently presents the results to the user. Server 102 can accept data from client 104 via the web browser (e.g., Microsoft Internet Explorer or Mozilla Firefox) and return the appropriate HTML or XML responses to the browser using network 112.
For example, the illustrated architecture can allow a developer to define queries (or a user to utilize queries) within one or more business application programs 145 that use one or more business object nodes 204. In this way, the business application programs 145 can meet the combined search needs of service consumers 206. Specifically, the business application 145 may use combined search queries to access one or more business objects and related attachments or files. For example, a combined search query provider 165 can divide a combined search query into a fast search service 210 and an attachment search service 212.
The fast search service 210 can use a fast search infrastructure or other query provider to execute the query. In this scenario, the fast search service 210 can provide query input to a search engine 214. After executing the query, the search engine 214 can provide the search results responsive to the query to the fast search service 210. The search results can be in the form of a list of business object node IDs corresponding to the business objects matching the query. The returned business object node IDs typically can represent instances of the business object node to which the query is attached (e.g., an “anchor” business object node). If the query uses the fast search infrastructure to execute the query, a fast search query provider can be registered with the query. Because the fast search infrastructure can allow the definition of queries across different business object nodes, the input structure can be mapped to fields of an underlying fast search view.
The attachment search service 212 of the combined search can also be an extension of the fast search query provider 165. The attachment search service 212 can use an application programming interface (API) 216 as an interface to a J2EE 218 where the attachment query is handled. The example J2EE 218 includes a repository framework web service 220 and an index management web service 222. The repository framework web service 220 can provide the web services used for accessing a repository framework 224. For example, the repository framework 224 can include definitions of the types of attachments that can be searched. The index management web service 222 can provide web services used for managing the indexes associated with the repository framework 224. Such indexes, for example, can be used to improve the efficiency by which repositories 226 are searched. The J2EE 218 can use the search engine 214 to execute attachment-based queries. Of course, the foregoing components are for illustration purposes only and other components in different arrangements may be used to implement the techniques described herein. For example, the fast search service 210 might be connected to one instance of search engine 214, while attachment search service 212 (as well as 218) might be connected to a different instance of search engine 214. Indeed, the two instances of search engine 214 might be based on different technologies and might reside on different devices.
The query received by the search query provider 165 is first appropriately split up or otherwise parsed into parts. Depending on the search scenario, the query can be executed in either or both the fast search service 210 and the attachment search service 212. Determining where the query is executed is handled by a query splitter 306. The outputs of services 210 and 212 are merged into a single output list by a result merger 308. While the query splitter 306 and result merger 308 form the framework for combined search, the fast search service 210 and the attachment search service 212 handle the respective execution of the search.
For example, upon receipt of a combined query for purchase orders of 11-mm ball bearings from a specific vendor, the query splitter 306 can split the combined query into two components: a first query component targeting business objects 140 and a second query component targeting one or more attachments 142. The query splitter 306 can provide the first query component to the fast search service 210 and the second query component to the attachment search service 212. The services 210 and 212 can then perform their corresponding searches. In particular, the fast search service 210 can use a search engine (e.g., search engine 214) to identify business objects responsive to the query. The result can be a list of purchase orders matching the query. Similarly, the attachment search service 212 can search designated attachments for purchase order business objects matching the query. For example, if the query is for purchase orders for 11-mm ball bearings from a specific vendor, the attachment search service 212 can provide a list of the query-matching purchase orders found within the specified attachments; e.g. purchase orders that have an attached file that includes the term “11-mm” in the full text, metadata, and so forth. The list of purchase orders can be, for example, in the form of a list of business objects.
After the services 210 and 212 provide their search results, the result merger 308 merges the results into a merged results set, such as the business object node IDs 304. A number of steps are necessary by the result merger 308 to ensure that the result lists (list of business object node IDs) are sorted, paged and merged correctly. Particularly, depending on the query scenario, the merged list may rely on objects that appear on both lists (e.g., as specified by an “AND” operation) or on either list (e.g., as specified by an “OR” operation).
Table 1 below, Input Structure for Combined Search Query Provider, shows an example input structure for the combined search query provider 165. For example, the query splitter 306 can receive such structures as the input structure 302, such as in a query received from a business application. The structure serves to provide the rules for scenario selection and data passing to the combined search query provider 165.
The query input structure can include fields that may be used for the fast search service 210 and the attachment search service 212. Apart from fields that can be mapped to view fields, the structure includes a field (i.e., FSI_SEARCH_TEXT) which is used for the phrase search string. As shown, Table 1 defines an example field for searching attachments (i.e., ATT_PHRASE_ATTR), and a similar field or structure can also be used for fast searches (i.e., not using attachments) and combined searches (i.e., using attachment and fast search services).
The phrase search string (i.e., FSI_SEARCH_TEXT) can be reused in a combined search. It sets the phrase that can be sent to the attachment search service 212. Two other fields are defined that are specific to a combined search. A scenario flag (i.e., SCENARIO) can be used to define how the search results from the two searches (i.e., fast service and attachment service) are to be combined. The attachment attribute string can be used to pass the attachment attributes to the query splitter 306. In this way, the query splitter 306 can instruct the services 210 and 212 to create result sets that the result merger 308 can combine according to the designated scenario.
The attachment attributes (i.e., ATT_PHRASE_ATTR) and search string can all be included in one combined string or other structure. When doing so, the name value pairs can be separated by separation markers. For example, the following syntax can be used. The beginning of the string can hold the search phrase, followed by the attributes. The same syntax used for the attachment search service 210 can be used for the fast search service 212.
Consider a query such as:
In this example, the query would search for documents that contain the terms “term1” and “term2” in their content or that have the document property DocumentType=“Offer” and Usage=“All.” Moreover, the various document properties can belong to multiple namespaces. Accordingly, the above example Http://namespace is a limiting namespace for the attributes “DocumentType” and “Usage”, respectively, to further target the search.
Table 2 below, Scenarios Possible for Combined Search Query Provider, lists example scenarios that are possible using the combined search query provider 165. For example, a scenario type of “B” can be used when the attachment capability of the combined search is to be bypassed, such as when just a fast search is to be performed (e.g., using object repositories). Similarly, a scenario type of “T” can be used when no search string is provided for a fast search. In this scenario, search text may still be provided for searching attachments. Other scenario types, such as “O” and “A,” can define how result sets from a combined search are to be merged. For example, the “O” scenario can represent the “OR” case in which the result merger 308 includes entries in the merged business object node IDs 304 if they appear on either object list produced by services 210 and 212. The “A” scenario can represent the “AND” case in which the result merger 308 includes entries in the merged business object node IDs 304 only if they appear on the object lists produced by both servers 210 and 212.
Table 3 below, Query Splitter and Result Manager, lists example methods that can be used by the combined search query provider 165. For example, one or more of the methods may be called or executed one or more times depending on the scenario. For example, in a scenario involving a query of business objects and non-structured attachments, methods such as callFastSearch and callAttachmentSearch may be used one or more times. Specifically, the method callFastSearch may be used to find matching business objects in the repository, while the callAttachmentSearch method may be used to search one or more attachments.
The particular methods executed (and the order in which they are executed) for a specific query can be determined by the query splitter 306 based on, for example, the Scenario Type parameter (e.g., refer to Table 2) passed with the input structure 302. These scenario-based behaviors are discussed below in reference to
The schematic illustrated in
In the “Bypass” search scenario, the search is initiated when the combined search interface 505 is executed at step 525. For example, the combined search query provider 165 may receive a query via the input structure 302 that is coded to use the “Bypass” scenario in which no attachments are to be searched. Specifically, the query may be designed to search only the structured data of object repositories. Because the query is for a “non-combination” search, the combined search interface 505 can immediately forward the query to the fast search service 520, passing the search attributes and the search phrase at step 530.
In the “AND” search scenario, the search is initiated when the combined search interface 505 is executed at step 605. For example, referring to
In some implementations, search calls can be arranged such that efficiencies in paging can be realized. The fast search call is set to retrieve twice the amount of hits that are required by the execute call. Assuming that fast search and the attachment search provide roughly the same number of hits, it can be assumed that only a fraction of the fast search hits will also be returned by the attachment call. In case the final result does not contain enough hits to fill the page, the fast search call can be repeated, retrieving the next page.
In the “OR” search scenario, the search is initiated when the combined search interface 505 is executed at step 705. For example, referring to
In some implementations, a “mixed” scenario can be used. For example, if the user specifies more than one search phrase, the phrases can be joined by an “AND.” The entire phrase can then be passed to the attachment and fast search services. Result sets where part of the search phrase is included in a fast search attribute and the other part is found in the attachment search can be returned as a potential hit. Each potential hit representing a combination of sub-phrases can be examined, and the results combined.
In the attachment-only search scenario, the search is initiated when the combined search interface 505 is executed at step 805. For example, the combined search query provider 165 may receive a query via the input structure 302. Specifically, the query may be one coded to use the attachment-only “T” scenario in which no fast search is to be done. In particular, the query may be designed to search one or more attachments but not the structured data of BO repositories. At step 810, the combined search interface 505 gets all nodes associated which the underlying view. The attachment search occurs at step 815 when the combined search interface 505 invokes the attachment service 515. At step 820, the attachment service 515 can invoke the administrator service 510 to get the anchor node associated with the BO node IDs before returning the search results to the combined search interface 505. At step 825, the result set of the search can be sorted.
Sorting can occur when the result merger 308 is called to merge the result lists produced by the fast search service 210 and the attachment search service 212. The getResults method can import a table of attachment hits and a table of fast search hits. The attachment hits first can be mapped to the anchor node of the fast search view. Then, the two tables can be combined according to the Boolean operator (e.g., “AND” or “OR”). The combination of the two tables can eliminate all duplicates. In a next step, the resulting tables can be sorted according to the fast search sorting criterion. This can be done by calling fast search without a search phrase and comparing the result with the entries of the table to be sorted. Finally, the requested page size is calculated and the result table is modified accordingly.
Table 4 below, Identifying a Business Object Node, identifies fields in a Business Object Node according to one implementation of the present disclosure. Specifically, a BO node can be identified by a combination of a BO name (e.g., purchase order, sales order, etc.), a BO node name, and a BO node ID.
Table 5 below, Definition for Property Based Search, identifies fields in a structure that can be used to specify how properties in attachments are searched. For example, combined searches, in addition to being operable to search the contents of attachments, can also search based on the attributes or properties of an attachment, such as the metadata associated with the attachment. In particular, the metadata can include numerical, textual, language-based, or other types of attributes of a particular attachment. For example, one attribute of an attachment can be the file name that may contain the name of a specific business object.
A particular property defined by the structure of Table 5 can have a specific namespace. Namespaces for properties may be defined according to a predefined syntax, such as a custom namespace table maintained on a web portal (e.g., http://XYZ123.com/˜/custom). A property can also have a property name, such as a file type or a file source, and a property value. For example, a property type such as “file type” may have a property value such as “email” or “spreadsheet.” Each property value can have a particular data type, which may be represented by an integer (e.g., 2=Date, 3=Integer, 5=String, etc.). A property operator field can describe possible ways for properties to be compared, and may be represented by integers (e.g., 0=Not Null, 1=Equal, 2=Not equal, 3=Between, 4=Greater, 5=Greater equal, 6=Less, 7=Less equal, etc.). An operator type can describe the type of property operator and can be represented by integers (e.g., 1=Operator (And/Or), 4=Open Bracket, 5=Closed Bracket, etc.). An action field (e.g., 1=Exact, 2=Fuzzy, 3=Linguistic) can identify the extent by which a property value can match a query. For example, an “exact” action may be used for an integer comparison. A “fuzzy” action, for example, may specify that one or more properties are to match closely (e.g., 80%) but not necessarily perfectly, or that as many as possible properties are to match. A “linguistic” action may, for example, allow matching by words or phrases that sound alike or are spelled similarly.
Beyond the examples in
Although this disclosure has been described in terms of certain embodiments and generally associated methods, alterations and permutations of these embodiments and methods will be apparent to those skilled in the art. For example, system 100 may include repository filters. With such filters, it can be possible to determine a property at run time directly in the repository framework. For example, if an attached document is accessed, such as during a search, the properties that contain information about the associated business object can be read from the corresponding attachment container. Specifically, the information can be available directly in the repository framework, such as in the J2EE 218, and can be visible at the resource itself. Such accessibility of information can improve performance of system 100. The combined search query provider 165 may use states in certain cases. For example, paging can be handled by states of the backend search engines (e.g., fast search). The state may be used only to save the current position in the fast search. This is not identical to the page the user is requesting. In some implementations, to help enable efficient calls to the attachment search service, the combined search can require an additional feature from the fast search infrastructure. For instance, the fast search call may not only retrieve the anchor business object node ID but also retrieve the business object node IDs of the nodes included in the fast search view. As this information is available with the fast search infrastructure, it can simply be passed via the API. A naming convention can be used to identify the BO nodes, as these are not necessarily view fields of the fast search view. Accordingly, the above description of example embodiments does not define or constrain this disclosure. Other changes, substitutions, and alterations are also possible without departing from the spirit and scope of this disclosure.
