Retrieval and conversion of query results from multiple query services

A system can receive an identifier for a query used by a query service of one or more query services and an identifier for the query used by an issuing computer system. The query service and the computer system that issued the query can use different schemas for query results. A mapping can be established that maps elements of one schema to the other schema. This mapping, and a mapping of the query identifiers, can be used to convert query results to a format useable by the computing system that issued the query. By converting query results from multiple query services, which may have different formats, to a common format of the issuing computing system, the use of multiple query services is facilitated.

FIELD

The present disclosure generally relates to retrieving query results for a query that may have been submitted to multiple query services. Particular implementations relate to retrieving query results from query services, converting them to a format useable by a computing device that submitted the query, and then sending the converted results to such computing device.

BACKGROUND

Interoperability and compatibility are ongoing issues in software design. In some ways, the advent of the internet has made these problems easier, but in other ways it has made them more complex. Although data transfer over the internet is governed by particular protocols, such as HTTP and TCP/IP, the format of the data as sent by one computing entity can be different than a format used by other computing entities.

To some extent, data formats can be made more consistent, or at least easier to use, with serialized formats such as JSON and XML. However, metadata, such as in a schema definition, may still differ between a serialized format sent by one computing entity and a format used by another computing entity. Moreover, different computing entities may provide serialized formats for information having the same basic purpose, but the encoding formats may differ (e.g., using XML rather than JSON), as well as the metadata used—in terms of the labels used for the metadata, an order or grouping (including a hierarchical grouping) of metadata elements, and datatypes associated with values for the metadata (e.g., one format may represent a value as a string, and another format may represent the value, for an equivalent metadata element, as an integer).

In addition, some of the values used by different systems for the same data object may differ. That is, a first computing entity may have assigned a first identifier to a first data object, but a second computing entity may use a second identifier for that data, represented as a second data object. Accordingly, room for improvement exists.

SUMMARY

Techniques and solutions are described for receiving query results from one or more query services. A system implementing disclosed techniques can receive an identifier for the query used by a query service and an identifier for the query used by the issuing computer system. The query service and the computer system that issued the query can use different schemas for query results. A mapping can be established that maps elements of one schema to the other schema. This mapping, and a mapping of the query identifiers, can be used to convert query results to a format useable by the computing system that issued the query. By converting query results from multiple query services, which may have different formats, to a common format of the issuing computing system, the use of multiple query services is facilitated.

In one aspect, a method is provided for retrieving a query result from a query service, converting the result to a format useable by a computing device, and sending the query result to the computing device. A first identifier is received. The first identifier is used by a first computing device to identify a first query posted to a first query service. A second identifier is received. The second identifier is used by the first query service to identify the first query.

At least a first query response to the first query is received from the first query service. The first query response is in a first schema, comprising a first plurality of metadata fields and having first values for at least a portion of the first plurality of metadata fields. It is determined that the at least a first query response is responsive to the first query. At least a portion of the first values are extracted from the at least a first query response.

A first instance of a query response schema is instantiated with at least a portion of the extracted first values. The query response schema has a second plurality of metadata fields, where at least a portion of the second plurality of metadata fields differ from at least a portion of the first plurality of metadata fields. The first instance of the query response schema is associated with the first identifier. The first instance of the query response schema is sent to the first computing device.

In another aspect, a method is provided for retrieving query results from first and second query services, converting the results to a format useable by a computing device, and sending the query results to the computing device. A first identifier is received. The first identifier is used by a first computing device to identify a first query posted to a first query service and at least a second query service. A second identifier is received. The second identifier is used by the first query service to identify the first query. A third identifier is received. The third identifier is used by the second query service to identify the first query.

At least a first query response to the first query is received from the first query service. The at least a first query response has a first schema comprising a first plurality of metadata fields and first values for at least a portion of the first plurality of metadata fields. At least a second query response to the first query is received from the second query service. The at least a second query response has a second schema comprising a second plurality of metadata fields and second values for at least a portion of the second plurality of metadata fields. It is determined that the at least a first query response is responsive to the first query. At least a portion of the first values are extracted from the at least a first query response.

A first instance of a query response schema is instantiated with at least a portion of the extracted first values. The query response schema has a third plurality of metadata fields. At least a portion of the third plurality of metadata fields differ from at least a portion of the first plurality of metadata fields. The first instance of the query response schema is associated with the first identifier. The first instance of the query response schema is sent to the first computing device.

It is determined that the at least a second query response is responsive to the first query. At least a portion of the second values are extracted from the at least a second query response. A second instance of the query response schema is instantiated with at least a portion of the extracted second values. The second instance of the query response schema is associated with the first identifier. The second instance of query response schema is sent to the first computing device.

In a further aspect, a method is provided for retrieving a query result from a query service, converting the result to a format useable by a first computing device using a mapping configuration, and sending the query result to the first computing device. A first identifier is received. The first identifier is used by the first computing device to identify a first query posted to a first query service. A second identifier is received. The second identifier is used by the first query service to identify the first query.

A first mapping configuration is received. The first mapping configuration maps at least a portion of elements of a first metadata schema used by the first query service to metadata elements of a second metadata schema used by the first computing device. The first mapping configuration is stored. At least a first query response, in the first metadata schema, for the first query is received from the first query service. It is determined that the at least a first query response is responsive to the first query. At least a portion of first values of metadata elements of the at least a first query response is extracted.

It is determined that the first query response is associated with the first mapping configuration. The first mapping configuration is retrieved. A first instance of the second metadata schema is instantiated by mapping at least a portion of the first values to metadata elements of the second metadata schema using the first mapping configuration. The first instance of the second metadata schema is associated with the first identifier. The first instance of the second metadata schema is sent to the first computing device.

The present disclosure also includes computing systems and tangible, non-transitory computer readable storage media configured to carry out, or including instructions for carrying out, an above-described method. As described herein, a variety of other features and advantages can be incorporated into the technologies as desired.

DETAILED DESCRIPTION

Interoperability and compatibility are ongoing issues in software design. In some ways, the advent of the internet has made these problems easier, but in other ways it has made them more complex. Although data transfer over the internet is governed by particular protocols, such as HTTP and TCP/IP, the format of the data as sent by one computing entity can be different than a format used by other computing entities.

To some extent, data formats can be made more consistent, or at least easier to use, with serialized formats such as JSON and XML. However, metadata, such as in a schema definition, may still differ between a serialized format sent by one computing entity and a format used by another computing entity. Moreover, different computing entities may provide serialized formats for information having the same basic purpose, but the encoding formats may differ (e.g., using XML rather than JSON), as well as the metadata used—in terms of the labels used for the metadata, an order or grouping (including a hierarchical grouping) of metadata elements, and datatypes associated with values for the metadata (e.g., one format may represent a value as a string, and another format may represent the value, for an equivalent metadata element, as an integer).

In addition, some of the values used by different systems for the same data object may differ. That is, a first computing entity may have assigned a first identifier to a first data object, but a second computing entity may use a second identifier for that data, represented as a second data object. Accordingly, room for improvement exists.

In a specific example, a software application may post a query to different computing systems where query responses can be provided. The query may be assigned an identifier by the software application, but assigned different identifiers by the computing systems to which the query was posted. The software application can have a schema, such as reflected in structured data representation, such as XML or JSON, or in a datatype (such as an abstract datatype, such as an instance of a particular class for an object type associated with the query response). The computing systems to which the query responses were posted may provide query responses in different formats, different schemas, or both, than each other, or the format used by the computing system that posted the query.

In many cases, users manually convert data, as reflected in a query response, between formats. For example, the computing system that post a query and receives one or more query responses can send its query results to a computing system used by the user. The user can manually request and read the data in the query response, and then manually enter the data into a software application used to manipulate query results, which can be the same software application where the query originated. However, this process can be extremely time consuming, particularly when many queries may be submitted, with tens or hundreds of query responses often received for each query.

The present disclosure provides technologies for facilitating receiving query responses, including query responses from different computing services/query service providers, where the services may use different APIs, provide query responses in different formats, or a combination thereof. A posting (or query) service adapter can be configured to retrieve query responses from one or more posting services. Typically, a configuration in the posting service adapter is created for each different API that is to be called. The posting service adapter can be expandable, and flexible, in that new posting services can be incorporated into the system (e.g., used with posting/queries) by creating a new configuration that works with the API of the new posting service. Similarly, if a posting service changes its API, the corresponding configuration of the posting service can be updated to work with the updated API.

After query results (e.g., one or more posting replies to a posting) are received, the query results can be converted to a format used by an end application. Thus, even though a variety of posting services can be used, and configurations updated or changed in the posting service adapter, these changes can be abstracted from the end application that uses the posting replies (i.e., query results). In a particular example, query results can be converted to an intermediate format, mapped by the posting service adapter from a schema used by the posting service to a schema used by the end application, converted to a format usable by the end application, and sent to the end application. The use of the intermediate format can facilitate the mapping process, and can also allow query results to be returned to different end applications that use different schemas/data formats.

Example 2—Example Computing Environment Facilitating Posting Queries to, and Receiving Query Results from, Multiple Query Services

FIG. 1illustrates a computing environment100in which disclosed technologies can be implemented. Generally, the computing environment100includes one or more clients106, one or more posting services108, at least one application110that receives posting requests from a client for posting queries to a posting service, and a posting service adapter112that receives query results (or posting replies) from one or more of the posting services, processes the results, and sends the processed results to the application in a format used by the application, where the results can then be sent or presented to the relevant client106.

The application110can include a user interface116. The user interface116can be accessed by the clients106, such as to create queries or to post queries to one or more of the posting services108. For example, a user may use the user interface116to create a query and select one or more of the posting services108to receive the query. The user interface116can also allow a user to view query results that may be received from a posting service108, such as through the posting service adapter112. In at least some cases, the application110may allow a user to receive information, including query results, from a posting service108in another manner, such by manually accessing a posting service and retrieving query results.

The application110can use postings or queries in a first format118. The first format can include one or both of a first schema and a first data format (e.g., an encoding format, such as JSON or XML, or an instance of an abstract datatype or object in an object-oriented programming language, where the application may convert between representations, such as an abstract datatype/object and a serialized representation in a format such as JSON or XML). The first format118is typically also associated with a first identifier, which can be used to distinguish between different postings (e.g., instances of the object or serialized object) from one another.

Similarly, the application110can use query results (or posting replies) in a first format120. Like postings in the first format118, the query results in the first format120can include one or both of a first schema and a first data format, which can be the same as, or different than, the schema/format used for the query. The query results120can be associated with first identifiers, which can be used to distinguish query results from one another. In at least some cases, a particular query result120can include a query result identifier and the identifier of the posting in the first format118. Including the identifier of the query in the query results in the first format120can assist in tracking to which posting given posting replies should be associated.

The application110can include a posting component122. The posting component122can be configured to send postings in the first format118to one or more of the posting services108. Typically, the posting component122sends the postings in the first format118to a posting service108by calling an API126of the relevant posting service108.

Typically, a posting service108will maintain postings in a second format128and query results in a second format130(which may be implemented generally as described for the postings/results118,120, except differing in one or both of schema/metadata or format, such as encoding format). The postings in the second format128and the query results in the second format130can be associated with respective identifiers, as described for the queries118/query results120. Typically, the identifiers used by the posting service108are different than the identifiers used by the application110, although in at least some cases the posting service can include at least the identifier of the posting in the first format118in the posting in the second format128or the query results in the second format130. The posting component122can, in at least some implementations, convert a posting in the first format118to the second format128, or to a format accepted by the API126of the relevant posting service108, where the API can be responsible for converting data received through the API to the second format.

A posting service108can receive, or generate, query results, and can store the query results in the second format130. In a specific example, a posting service108can cause a posting to be displayed to a plurality of users (which can be considered a type of client106), who can reply or respond to the query (such as through the API126) to provide query results stored as the query results in the second format130. In other cases, a user may store information on a posting service108, and can indicate whether this information should be used to generate posting results for a given posting.

The posting service adapter112can be configured to automate, or at least help automate, a process of transferring query results in the second format130to the application110. Even putting aside format differences, it can be time consuming and cumbersome for a user (e.g., a client106) to request query results for multiple postings on multiple posting services108. The posting service adapter112can map the identifier for a given posting in the first format118to a particular posting service108to which the posting was submitted (e.g., by the posting component122).

The posting service adapter112can service requests (e.g., from the application110, which can originate at a client106), to request query results for a given query (or for multiple queries) from all, or selected members of, the posting services108to which the posting was submitted. The posting service adapter112can further facilitate automation by converting query results between the second format130, or the format provided by the API126, and a format used by the application110(e.g., the first format120, or a format in which the application is configured to receive query results, which are then converted to the first format).

The posting service adapter112can include a user interface134. The user interface134can allow a user (e.g., a client106, or an administrator of a computing system, such as a cloud computing system, on which the posting service adapter is hosted) to configure the posting service adapter112to access particular posting services108, or to take various actions with respect to a posting service, such as to retrieve query results130. To this end, the user interface134can include a posting service configuration component136and a data transfer configuration component138.

The posting service configuration component136can be used to create a profile for a posting service108. The profile can include information regarding the API126of a given posting service, including a location of the API (e.g., a URI), methods in the API (for example, for retrieving query results for a posting associated with a given identifier, such as used in the posting in the second format128), and information useable in converting query results received from the query results in the second format130to the query results in the first format120. Information useable in converting query results between formats can include information useable to map from a schema associated with the second format130to a schema associated with the first format120, or converting data between datatypes.

As an example, an element of the query results in the second format130may represent a particular value (e.g., a value associated with a particular metadata element of a schema), such as a calendar date/time, as a string, while the corresponding metadata element of the query results in the first schema120may represent the value in a particular time unit datatype (e.g., day/month/year/hours/minutes/seconds/milliseconds). Converting from the query results in the second format130can also include converting from a particular file or encoding format sent by the API126, such as converting data from an XML representation or a JSON representation to an intermediate format that is further processed by the posting service adapter112, and is eventually converted to the query results in the first format120.

The data transfer configuration component138can be used by a user (such as a client106) to interact with the posting service adapter112to take various actions with respect to a posting service108. For example, a user (e.g., a client106, including in association with the application110) can provide a posting identifier, such as the identifier associated with a posting in the first format118or an identifier associated with a posting in the second format128, and receive corresponding query results. In some cases, the data transfer configuration component138can allow a user to select whether to receive query results from one or more particular, selected posting services108, or to receive query results from all relevant posting services. In addition to providing the ability for a user to manually request query results, the data transfer configuration component138can allow a user to schedule the retrieval of query results from one or more posting services, such as at a specific time/date, or according to a schedule or at set intervals, such as every night, every week at a particular time, etc.

A controller component or software layer142can include a configuration controller144. The configuration controller144can interact with the posting service configuration component136to create, store, update, or delete profiles for a posting service108. In turn, the configuration controller144can call a mapping service150of a service software layer148, which can create mapping objects (or entities, which can be tables, or entries in tables, in a database156, or other data store)152(i.e., query results schema mapping objects, or schema mapping objects) that can be stored by a persistence layer154(such as in the database).

A data transfer controller158of the controller component142can communicate with a data transfer service160. In response to calls by the data transfer controller158, the data transfer service160can issue requests to pull query results (e.g., query results in the second format130, as returned by the API126) from the posting services108. Responses from the posting services108can be received by a query results parser162of the service layer148. The query results parser162can retrieve mapping objects152through the mapping service150. Using the appropriate mapping object152for a given posting service108, the parser162can extra data elements from query results. For example, the parser162can extract values for various metadata elements from the query results and produce a query results object164that can be sent to the application110.

In some cases, the parser162can directly convert from a query results format provided by a posting service108to a query results object164. In other cases, the parser162can convert query results provided by a posting service108to a query results object164by first generating a representation of the query results in an intermediate format (not shown). The intermediate format can be a generalized format that can be used for query results from any of the posting services108. Query results in the generalized, or intermediate, format can then be mapped to a format used for the query results object164.

In order to assist the application110in correlating query results provided in a query results object164to a particular query, it can be useful for the posting service adapter112to map identifiers for the queries in the first format118to identifiers used in the queries in the second format128. Accordingly, a query mapping API166of the posting service adapter112can receive query identifiers from the application110. In a specific use case, when the posting component122of the application110posts a query to a posting service108, the posting component122receives the value of the identifier of the query in the second format128. The application110can then call the query mapping API166, sending the identifier of the query in the first format118and the identifier of the query in the second format128.

The API166can send the query identifiers to a query mapping service168of the service layer148. The identifiers can be sent as a pair including the identifier for the query in the first format118and a single query in the second format128for a single posting, as a tuple including the identifier for the query in the first format and identifiers for multiple queries in the second format (e.g., corresponding to the same query from the application110, but at different posting services108), or as larger or more complex data collections (e.g., a series of tuples/records for multiple postings by the application, to one, or optionally a plurality, of the posting services).

The query mapping service168can produce query mapping objects170. A query mapping object170can be used to assign the identifier of the query in the first format118to a query results object164. Query mapping objects170can be persisted by the persistence layer154, such as to the database156. In a particular example, query mapping objects170can be represented as records in one or more database tables (for example, a table that has an attribute for “first format query identifier” and an attribute for “second format query identifier).

An application transfer service174can transfer query results, such as using query result objects164, to the application110, where the query results can be stored as the query results in the second format120. In a particular example, the application transfer service174can use a web-based protocol, including protocols that comply with REST principles. In a more particular example, the application transfer service174can transfer information in query results objects164to the application110using the ODATA protocol.

Example 3—Example User Interface Screen for Metadata Schema Mapping

As described in Example 2, query results (e.g., responses to a posting) can be provided in a different format than a format used by an application which requested the posting. In general, different applications may use different formats, and the present disclosure provides technologies for converting between such formats.

Typically, a format for query results includes a plurality of metadata fields, to which one or more values may be assigned. However, not all formats need include all possible fields, and fields can be named and ordered or grouped (including hierarchically) differently between formats. Similarly, for otherwise equivalent metadata elements, a metadata element in one format may have a different datatype than the equivalent metadata element in another format.

FIG. 2is an example user interface screen200that can allow a user to map a first query results format to a second query results format. The user interface screen200can be provided by the user interface134ofFIG. 1, such as corresponding to at least a portion of the posting service configuration component136. The screen200can include a field208allowing a user to select a source metadata source (e.g., a source file or data object). A user can browse for a source metadata source by selecting a control210, and can choose to upload (or otherwise load) the source metadata source using button212. In at least some cases, source metadata sources can be in different formats or types, and radio buttons214can allow a user to specify a source type (e.g., a source format, such as an encoding format, for example JSON or XML). A source format can be a format used by an application that will process query results, such as query results in the first format120as used by the application110ofFIG. 1.

In a similar manner, a field220can allow a user to select a target metadata source, including browsing for a source using a control222. Radio buttons224can allow a user to select a file, or format, type for the target metadata source, data from which can be uploaded to the screen200by selecting an upload icon226.

Although the screen200is shown with the fields208,220for a user to select source and target metadata sources, in some cases, one or both of these fields can be omitted. For example, a user may manually enter schema information in the screen200.

A mapping section230of the screen200can present fields234for elements (or attributes) of the source data schema and fields236for elements (or attributes) of the target data schema. In a particular implementation, elements from an uploaded metadata schema (e.g., selected using the field208) are populated to the fields234.FIG. 2also shows fields238that provide the datatype for a respective field234, and fields240that provide the datatype for a respective field236. A software component, such as the parser162, can include logic for converting between datatypes used by the target metadata format and the source metadata format.

The fields236can include dropdown selectors244, which can be used to select from elements read from a target metadata source, such as a target metadata source provided in the field220. That is, the elements of the target metadata source can define the options from which a user may select using the dropdown selectors244. Typically, application logic is provided such that a given element of the target metadata source can only be assigned or mapped to a single element (e.g., field234) of the source metadata.

In some cases, a user can elect to enter a default value for a given source element/target element mapping (e.g., a row of the mapping section230) in a corresponding default value field248. The default value can be a value that will be assigned to the corresponding source element234if a value is not received from query results having the target metadata schema, or if the target metadata schema does not include an equivalent element that can be mapped to the source metadata schema (or a target metadata element is otherwise not mapped to a given source metadata element).

There need not be, in all cases, an exact correspondence between fields of the source metadata and fields of the target metadata. That is, one or both metadata schemas can have one or more elements that are not present in the other. Typically, if the target metadata schema contains elements that are not present in the source metadata schema, those target metadata elements are simply not mapped to, or otherwise included in or accounted for in, the source metadata (i.e., it can be presumed that the application110does not “care” about those metadata elements). If the source metadata includes metadata elements that do not have a corresponding target metadata element, the application110may include logic for handling such omitted information (including for simply ignoring its absence). Or, as described above, a user can enter default values for unmapped source elements234in a corresponding default value field248.

Once a mapping is completed, it can optionally be assigned an identifier using a field260and then saved if a user selects a save icon262. Typically, the identifier provided in the field260can be used to associate the mapping with a particular posting service (e.g., a particular posting service108). Optionally, the mapping may be associated with other information, such as information identifying the application110(or a computing system on which the application is executing, a particular user, a particular query type, combinations of these data elements, etc.). In other cases, an identifier can be associated with the mapping in another manner, such as automatically by the posting service configuration component136or the configuration controller144. Typically, the mapping is associated with an identifier that allows the mapping to be associated with a particular posting service (and optionally one or more of the features noted above, such as an identifier of the application110, a user identifier, etc.).

Example 4—Example User Interface Screen Displaying Query Identifier Mappings

FIG. 3illustrates a user interface screen300that can allow a user to view, and optionally take various actions regarding, queries posted to a posting service. The user interface screen300can be provided by the data transfer configuration component138of the user interface134ofFIG. 1.

The screen300includes a table306having a column with fields310providing an identifier used by an application associated with a posting or query, such as the application110. The table306further includes a column with fields314providing an identifier used by a posting service (e.g., a posting service108), where a row of the table thus provides a tuple that associates a given posting identifier for a posting service in a field314with a corresponding posting identifier for an application in the field310. Note that a given application posting identifier in a field310can be appear in multiple rows, having different identifiers for different posting services in a column having fields320. That is, for example, rows324a,324b,324chave the same value in field310, but different values in the field314, where the value in field320identifies a particular posting service to which the query was posted. Each row can also be associated with a posting time, in a column having fields330.

In some cases, rows of the table306can be selectable, or a user otherwise enabled to select a particular tuple of the table, where selection of a tuple causes query results for the tuple to be retrieved. In at least some cases, a posting service adapter of the present disclosure, such as the posting service adapter112ofFIG. 1, can be configured to maintain identifiers for individual query results received from posting services108. That is, query results can be in the form of discrete results, or responses to a posting, having unique identifiers, even if multiple responses are included in a single communication from a posting service. These query response identifiers can be stored. When query results are received from a posting service, a component of the posting service adapter (such as the parser162) can determine whether any of the query results were previously received by the posting service adapter, and returned to the application110. If so, those query results can be omitted from further processing, including not being sent (again) to the application110. In this way, the posting service adapter112can avoid sending duplicative query results to the application, which can conserve processing resources at the posting service adapter112, and network resources in transferring query results from the posting service adapter to the application110.

AlthoughFIG. 3has been described as providing for manually-triggered retrieval of query results, in at least some implementations disclosed technologies can provide for automatically triggered or scheduled retrieval of query results, in addition to, or in place of, manual retrieval. Scheduling can include retrieving results at one or more specified times, or according to a schedule, such as at particular intervals (e.g., daily, weekly). Typically results are “pulled” from a posting service108, but the posting service adapter112can be configured to respond to “push” requests from a posting service, if supported by a given posting service.

Example 5—Example Application of Disclosed Technologies to Recruiting Scenario

Recruiting is a particular area in which the technologies discussed in Examples 1-4 may find use. While there are many ways of recruiting, a common way is for hiring personnel of a particular entity to post job openings to one or more job boards. The hiring personnel can use software applications that are particularly designed for recruiting activities, such as the SAP SuccessFactors product of SAP SE, of Walldorf, Germany.

Recruiting software may include functionality to post a particular job to multiple job boards (e.g., posting services108ofFIG. 1). The recruiting software may have functionality to convert a given job posting to a format used by a job board, and to call APIs of the posting service to post the job. However, typically the hiring personnel must manually log onto a job board to determine whether any candidates have applied. If candidates have applied, the hiring personnel may review candidate information and enter that information back in the recruiting software used by the entity. This process can be time consuming and error prone.

Using technologies described in the present disclosure, hiring personnel, or other users, can configure a posting service adapter (such as the posting service adapter112ofFIG. 1) to map candidate profiles as maintained in their recruiting software to candidate profiles as provided by a posting service. The hiring personnel can then manually cause candidate profiles to be retrieved from the posting services, converted to the format used by the recruiting software, and sent to the recruiting software. Or, automatic retrieval of candidate profiles can be scheduled, or triggers set.

Candidate profiles provided by a job board can be associated with a particular metadata schema, which can be hierarchically organized. For example, a candidate profile will typically contain elements such as a candidate's name, social security number, date of birth, address and other contact information, work history, and educational history. Some of these elements, such as work history and educational history, may have sub-elements such as company or school name, dates employed or school attended, employer or school address or contact information, etc. These metadata elements may have different names, organizations, datatypes, or combinations thereof, than a schema used by the recruiting software. Mapping between a job board and the recruiting software can include mapping metadata elements from one schema to metadata elements of the other schema, and optionally converting between datatypes used in the different schemas.

Candidate profiles may be provided in different encoding or file formats, such as being sent by a posting service in XML or JSON. However, the recruiting software may be configured to use candidate profiles in another format, such as instances of an abstract datatype or an object in an object oriented programming language. A posting service adapter, used in the recruiting context, can convert candidate profiles from an XML or JSON representation to an intermediate format used by the posting service adapter. The intermediate representation can be an instance of a class or object defined to represent a candidate profile. This intermediate format can then be converted for use by, or for sending to, the recruiting software, where the profiles can be instantiated as instances of the class/object of the recruiting system.

FIGS. 4-6illustrate how query results, in the form of candidate profiles by job boards in response to a job posting, can be converted from a format provided by the job board, to an intermediate format, and then to a format used by recruiting software.FIGS. 4A-4Fpresent XML code for a partially completed candidate profile400. The profile400includes a plurality of hierarchically arranged metadata elements404. Values408are provided for a portion of the metadata elements. The profile400can represent candidate profiles provided by a first job board in response to a job posting.

FIGS. 5A-5Hillustrate an alternative XML candidate profile500representation as provided by another job board. The candidate profile representation500can include multiple candidate profiles510that are responsive to a given job posting. As with the profile400, each profile510can include various metadata elements514, where values518are provided for at least some of the metadata elements.

FIG. 6provides a JSON representation of a candidate profile600that can be sent by a job board. The candidate profile600includes a plurality of metadata elements608, at least some of which are associated with values614, and thus form attribute-value pairs.

A posting service adapter according to the present disclosure can include a parser that retrieves mapping information for a given job board, reads the format in which candidate profiles are provided by a job board (e.g., in XML or JSON), extract values for metadata elements, and uses the mapping information to assign the values to a format to be sent to the recruiting system. In carrying out the extracting and assigning, the parser can also convert values between datatypes, if there is a difference between a datatype used for a metadata element by a job board and the datatype of the element in the format used by the recruiting service.

FIG. 7presents JAVA source code700for a RawCandidate class. The RawCandidate class can represent an intermediate format that can be used to hold data extracted (such as by the parser162) from candidate profiles received from a job board. The source code700defines data members for the RawCandidate class that include a string708for an identifier assigned to the profile, an object710(e.g. another abstract datatype) that includes the actual applicant information for the candidate, a byte array712that can be used to hold an attachment provided by the applicant (e.g., a pdf version of a cover letter or resume), and a string714that represents the file type of the byte array. Additional data members can include a string716that holds the name of the applicant (candidateName) and a string718that holds the job posting identifier for the job opening to which the candidate is applying (which, depending on the implementation, can be the identifier associated with the query in the first format118or the identifier associated with the query in the second format128). The code700defines various methods730, including “setter” and “getting” methods for the various data members.

Note that the object datatype used for the profile data member710can be a very general datatype, and can be used to hold XML or JSON data, for example. So, an instance of the RawCandidate class can be used to store basic information regarding a candidate, and hold the candidate's profile (e.g., in a format shown inFIG. 4A-4F, 5A-5H, or6) in the object abstract datatype where it can be further processed (e.g., by the parser162) to provide a representation of the candidate that can be sent to the recruiting software.

FIG. 8presents JAVA source code800for a ParsedCandidate class. The ParsedCandidate class can be used to hold information extracted from an instance of the RawCandidate class. The ParsedCandidate class can be a format that can be sent to, and used by, the recruiting software, which can be serialized and sent to the recruiting software (where it can be converted, for example, to a representation, such as an instance of a class, in the format used by the recruiting software), or which can be provided to the recruiting software via an API of the recruiting software (where it can be converted, for example, to a representation, such as an instance of a class, in the format used by the recruiting software). The code800includes data members for a profileHeader object810(described in the code900ofFIG. 9), a resumeAttachment object812(described in the code1000ofFIG. 10), and a list814of properties for the candidate (where a property is described in the code1100ofFIG. 11).

The code800also declares various methods, including a method820to set the values for the profileHeader data member810and the resumeAttachment data member812. A method824allows specific properties provided as arguments to be retrieved from the properties data member814. A method828allows new properties to be added to the properties data member814, such as during parsing of the object710of an instance of the RawCandidate class being processed to produce an instance of the ParsedCandidate class. Similarly, a method832can allow a list of properties to be added to the properties data member814.

The code800declares a method836for getting the profileHeader data member810, and a method840for getting the resumeAttachment data member812.

The code900can include various methods920, such as methods to set and get the values for the various data members910,912,914.

FIG. 10presents the example JAVA code1000for the resumeAttachment abstract datatype. The resumeAttachment can be used to store one or more attachments that may have been provided by a candidate, such as a resume or a cover letter. The resumeAttachment abstract datatype can have a data member1010, a string that can be a URL for the attachment. A content data member1012, having the byte array type, can be used to hold the content of the attachment, while a string data member1014can be used to store the file name of the attachment. A data member1016can have a FileExtension datatype, and can be used to store an identifier of the file type of the attachment whose data is stored in the data member1012. Methods1020can be provided to set and get the values of the data members1010,1012,1014,1016.

FIG. 11presents example JAVA code1100for the FileExtension datatype, which can be an enumerated datatype, which can include values1110for various file type extensions. A data member1112can store the value of the extension, as a string. A method1114can be used to set the value of the data member1112, while a method1116can be used to get the value of the data member1112. Methods1120,1122can be used, respectively, to create a hash map of file extensions and string representations of the extension, and return a file extension for a given string input.

FIG. 12presents example JAVA code1200that defines an interface for a Property. The interface includes a method1210that returns a Boolean value indicating which a given instance of Property is a required property, and a method1212returns a Boolean value indicating whether a given instance of Property is a navigation property. Methods1214,1216, can be used, respectively, to return the identifier, in the form of a string, for a given property, as used in the recruiting software, and a string representing an entity type for the instance of Property.

FIG. 13presents example JAVA code1300for a NavigationProperty class. The NavigationProperty class implements the Property interface of the code1200ofFIG. 12. The code1300defines various data members, including a string1310for a property identifier used by the recruiting software, a string1312for an entity type, and a string1314for a navigation entity type. Boolean data members1316,1318can indicate, respectively whether the instance of NavigationProperty is required, and whether the instance includes multiple properties. A data member1320is a list that holds instances of abstract datatypes that implement the Property interface.

The code1300includes a method1330can be used to set the values of the data members1310,1312,1314,1318. Methods1332,1334,1336,1338override the corresponding methods1214,1216,1210,1212of the Property interface provided in the code1200ofFIG. 12. Method1342can be used to set the value of data member1316as required. Method1344can be used to return the data member1320, while method1346can be used to add instances of abstract datatypes implementing the Property interface to the data member1320. A method1348can be used to obtain the value of the data member1314, while a method1350can be used to obtain the value of the data member1318.

FIG. 14illustrates JAVA code1400for a SimpleProperty class, and JAVA code1450for a SimplePropertyBuilder class. The SimpleProperty class implements the Property interface1200ofFIG. 12, and includes a string data member1406for a property identifier as used in the recruiting software, a data member1408of the object datatype to hold a value of an instance of the SimpleProperty class, a string data member1410to hold a value of the entity type of the instance, and a Boolean data member1412indicating whether the instance is required (e.g., if a candidate profile will be valid if a value corresponding to this data member is not found).

A method1416can be used to set the properties of the data members1406,1408,1410,1412by taking an instance of the SimplePropertyBuilder class as an argument.

The code1450for the SimplePropertyBuilder class includes a string data member1452for a property identifier as used in the recruiting software, a data member1454of the object datatype and holding a value for the instance, and a string data member1456holding an entity type for the instance. The data members1452,1454,1456are assigned default values of NULL. A Boolean data member1458is used to indicate whether the instance is required, and is defaulted to FALSE.

A method1464can be used to return an instance of the SimpleProperty class to an initial state—resetting the values of the data members1452,1454,1456to NULL, and the value of the data member1458to FALSE. Methods1470can be used to set/get the values of the data members, while the methods1474override the methods1210,1212,1214,1216of the Property interface of the code1200ofFIG. 12.

In practice, when query results from a job board are received, profiles for individual candidates are converted to instances of the RawCandidate class described in the code700ofFIG. 7. The profile data member710can be parsed (e.g., using syntax elements of XML or JSON, such as “/” or semicolon delimiters, to identify attributes/values) to extract various values for various properties in the metadata schema used by the job board. The mapping for the job board can be retrieved, and used to assign entity types (e.g., metadata tags from the schema used by the recruiting software) to the values, which types can be included as properties in an instance of the ParsedCandidate class of the code800ofFIG. 8.

The identifier used by the recruiting software for the job posting to which the candidate is applying can be retrieved from mapping information using the identifier for the job posting used by the relevant job board, and then associated with the ParsedCandidate. The ParsedCandidate then can be sent to the recruiting application, either as the instance of the ParsedCandidate, sending a serialized version of the instance to the application, or sending the information for the ParsedCandidate using an API of the recruiting application.

Example 6—Example Operations in Receiving, Converting, and Sending Query Results in Different Schemas

FIG. 15illustrates operations in a method1500for retrieving a query result from a query service, converting the result to a format useable by a computing device, and sending the query result to the computing device. The method1500can be carried out, in a particular implementation, using the computing environment100ofFIG. 1.

At1510, a first identifier is received. The first identifier is used by a first computing device to identify a first query posted to a first query service. A second identifier is received at1514. The second identifier is used by the first query service to identify the first query. At1520, at least a first query response for the first query is received from the first query service. The first query response is in a first schema, comprising a first plurality of metadata fields and having first values for at least a portion of the first plurality of metadata fields. It is determined at1524that the at least a first query response is responsive to the first query. At1528, at least a portion of the first values are extracted from the at least a first query response. A first instance of a query response schema is instantiated at1532with at least a portion of the extracted first values. The query response schema has a second plurality of metadata fields, where at least a portion of the second plurality of metadata fields differ from at least a portion of the first plurality of metadata fields. At1536, the first instance of the query response schema is associated with the first identifier. The first instance of the query response schema is sent to the first computing device at1540.

FIG. 16illustrates operations in a method1600for retrieving query results from first and second query services, converting the results to a format useable by a computing device, and sending the query results to the computing device. The method1600can be carried out, in a particular implementation, using the computing environment100ofFIG. 1.

At1610, a first identifier is received. The first identifier is used by a first computing device to identify a first query posted to a first query service and at least a second query service. A second identifier is received at1614. The second identifier is used by the first query service to identify the first query. A third identifier is received at1618. The third identifier is used by the second query service to identify the first query.

At1622, at least a first query response to the first query is received from the first query service. The at least a first query response has a first schema comprising a first plurality of metadata fields and first values for at least a portion of the first plurality of metadata fields. At1626, at least a second query response to the first query is received from the second query service. The at least a second query response has a second schema comprising a second plurality of metadata fields and second values for at least a portion of the second plurality of metadata fields. It is determined at1630that the at least a first query response is responsive to the first query. At1634, at least a portion of the first values are extracted from the at least a first query response.

A first instance of a query response schema is instantiated at1638with at least a portion of the extracted first values. The query response schema has a third plurality of metadata fields. At least a portion of the third plurality of metadata fields differ from at least a portion of the first plurality of metadata fields. At1642, the first instance of the query response schema is associated with the first identifier. The first instance of the query response schema is sent at1646to the first computing device. At1650, it is determined that the at least a second query response is responsive to the first query. At least a portion of the second values are extracted at1654from the at least a second query response. At1658, a second instance of the query response schema is instantiated with at least a portion of the extracted second values. The second instance of the query response schema is associated with the first identifier at1662. At1666, the second instance of query response schema is sent to the first computing device.

FIG. 17illustrates operations in a method1700for retrieving a query result from a query service, converting the result to a format useable by a first computing device using a mapping configuration, and sending the query result to the first computing device. The method1700can be carried out, in a particular implementation, using the computing environment100ofFIG. 1.

At1710, a first identifier is received. The first identifier is used by a first computing device to identify a first query posted to a first query service. A second identifier is received at1714, the second identifier is used by the first query service to identify the first query. At1718, a first mapping configuration is received. The first mapping configuration maps at least a portion of elements of a first metadata schema used by the first query service to metadata elements of a second metadata schema used by the first computing device. The first mapping configuration is stored at1722. At1726, at least a first query response, in the first metadata schema, for the first query is received from the first query service. It is determined at1730that the at least a first query response is responsive to the first query. At1734, at least a portion of first values of metadata elements of the at least a first query response is extracted. It is determined at1738that the first query response is associated with the first mapping configuration. The first mapping configuration is retrieved at1742. At1746, a first instance of the second metadata schema is instantiated by mapping at least a portion of the first values to metadata elements of the second metadata schema using the first mapping configuration. The first instance of the second metadata schema is associated with the first identifier at1750. At1754, the first instance of the second metadata schema is sent to the first computing device.

Example 7—Computing Systems

FIG. 18depicts a generalized example of a suitable computing system1800in which the described innovations may be implemented. The computing system1800is not intended to suggest any limitation as to scope of use or functionality of the present disclosure, as the innovations may be implemented in diverse general-purpose or special-purpose computing systems.

With reference toFIG. 18, the computing system1800includes one or more processing units1810,1815and memory1820,1825. InFIG. 18, this basic configuration1830is included within a dashed line. The processing units1810,1815execute computer-executable instructions, such as for implementing components of the computing environment100ofFIG. 1, including as described in Examples 1-6. A processing unit can be a general-purpose central processing unit (CPU), processor in an application-specific integrated circuit (ASIC), or any other type of processor. In a multi-processing system, multiple processing units execute computer-executable instructions to increase processing power. For example,FIG. 18shows a central processing unit1810as well as a graphics processing unit or co-processing unit1815. The tangible memory1820,1825may be volatile memory (e.g., registers, cache, RAM), non-volatile memory (e.g., ROM, EEPROM, flash memory, etc.), or some combination of the two, accessible by the processing unit(s)1810,1815. The memory1820,1825stores software1880implementing one or more innovations described herein, in the form of computer-executable instructions suitable for execution by the processing unit(s)1810,1815.

A computing system1800may have additional features. For example, the computing system1800includes storage1840, one or more input devices1850, one or more output devices1860, and one or more communication connections1870. An interconnection mechanism (not shown) such as a bus, controller, or network interconnects the components of the computing system1800. Typically, operating system software (not shown) provides an operating environment for other software executing in the computing system1800, and coordinates activities of the components of the computing system1800.

The tangible storage1840may be removable or non-removable, and includes magnetic disks, magnetic tapes or cassettes, CD-ROMs, DVDs, or any other medium which can be used to store information in a non-transitory way and which can be accessed within the computing system1800. The storage1840stores instructions for the software1880implementing one or more innovations described herein.

The input device(s)1850may be a touch input device such as a keyboard, mouse, pen, or trackball, a voice input device, a scanning device, or another device that provides input to the computing system1800. The output device(s)1860may be a display, printer, speaker, CD-writer, or another device that provides output from the computing system1800.

In various examples described herein, a module (e.g., component or engine) can be “coded” to perform certain operations or provide certain functionality, indicating that computer-executable instructions for the module can be executed to perform such operations, cause such operations to be performed, or to otherwise provide such functionality. Although functionality described with respect to a software component, module, or engine can be carried out as a discrete software unit (e.g., program, function, class method), it need not be implemented as a discrete unit. That is, the functionality can be incorporated into a larger or more general-purpose program, such as one or more lines of code in a larger or general-purpose program.

Example 8—Cloud Computing Environment

FIG. 19depicts an example cloud computing environment1900in which the described technologies can be implemented. The cloud computing environment1900comprises cloud computing services1910. The cloud computing services1910can comprise various types of cloud computing resources, such as computer servers, data storage repositories, networking resources, etc. The cloud computing services1910can be centrally located (e.g., provided by a data center of a business or organization) or distributed (e.g., provided by various computing resources located at different locations, such as different data centers and/or located in different cities or countries).

The cloud computing services1910are utilized by various types of computing devices (e.g., client computing devices), such as computing devices1920,1922, and1924. For example, the computing devices (e.g.,1920,1922, and1924) can be computers (e.g., desktop or laptop computers), mobile devices (e.g., tablet computers or smart phones), or other types of computing devices. For example, the computing devices (e.g.,1920,1922, and1924) can utilize the cloud computing services1910to perform computing operators (e.g., data processing, data storage, and the like).

For clarity, only certain selected aspects of the software-based implementations are described. It should be understood that the disclosed technology is not limited to any specific computer language or program. For instance, the disclosed technology can be implemented by software written in C, C++, C#, Java, Perl, JavaScript, Python, Ruby, ABAP, SQL, XCode, GO, Adobe Flash, or any other suitable programming language, or, in some examples, markup languages such as html or XML, or combinations of suitable programming languages and markup languages. Likewise, the disclosed technology is not limited to any particular computer or type of hardware.