Data structure for multiple executable tasks

A system, method, and computer-readable medium, including receiving a request to create a job chain, the job chain being a data structure and to reference a plurality of simple jobs; specifying the plurality of simple jobs referenced by the job chain, each of the simple jobs including at least one attribute defining an executable task for the simple job; specifying an order of execution for the plurality of simple jobs referenced by the job chain; and generating an instance of the job chain data structure, the generated job chain referencing the plurality of simple jobs and inheriting the at least one attribute of each of the plurality of simple jobs.

BACKGROUND

Enterprise software systems receive, generate, and store data related to many aspects of a business enterprise. This data may relate to sales, customer relationships, marketing, supplier relationships, inventory, human resources, and/or finances. Users operate reporting tools to access such data and display the data in useful formats, such as graphic visualizations and reports.

Reports related to the stored data may be generated relating to the tasks performed by a software application, service, and computing system or device of an organization. Some tasks may be straight-forward, including a single process or task that can be readily captured and expressed in different analytics and reports. In some contexts, software application(s), a service, a computing system, a device, and combinations thereof may be configured and implemented to execute a processor-executable task, wherein some aspects of the executed task can be included (i.e., “reported”) in a report. However, some processes, actual or potential actualities, may comprise a plurality of different processor-executable tasks that might be performed repeatedly, even at intervals.

DETAILED DESCRIPTION

The following description is provided to enable any person in the art to make and use the described embodiments. Various modifications, however, will remain readily apparent to those in the art.

In some example contexts, use-cases, and embodiments, one or more application jobs (also referred to simply as “jobs” herein) may be executed when an application, service, system (e.g., server), or device is invoked and/or makes a call to or requests the execution of the application job. In some aspects, the jobs may execute or run in the background of an application, service, or system, without direct interaction with a user. For example, an invoicing process to create invoices for a business organization may be represented by a business object data structure and modeled by a developer or other entity. Parameters (e.g., variables, etc.) and other defining aspects of the modeled business object may be specified by metadata associated with the model thereof. Instances of the modeled invoice process may be generated with specific values for the parameters thereof, where the specific values might be obtained from a user and/or other applications or sources. In a like manner, other processes may be modeled and defined by associated metadata. For example, another background process might be a dunning process for sending reminder letters to customers having outstanding invoices.

In one example embodiment, background processing may be based, in large part, on reports that can be used by an organization to support their real-world operations. In some aspects, a simple job may be invoked to repeat periodically. For example, an organization may run an invoicing process once a month, although other time intervals may be possible.

While automatically running a simple job comprising a single task (e.g., create invoices, or generate a dunning letter, etc.) as a background application might be beneficial, some real-world challenges may involve processes including multiple steps or tasks. In some example embodiments herein, a process for creating and using jobs including a plurality of steps or tasks is disclosed. The jobs herein including a plurality of steps or tasks are referred to as job chains.

In some aspects, a job chain is a modeled data structure having associated metadata specifying attributes of the job chain. In some systems, a job catalog entry is based on a report and the job catalog entry is used to specify, in a job catalog, the different jobs available and possible for execution by a system or service. In some aspects, a job catalog entry may include attributes arranged in sections such as, for example, “header”, “group”, and “parameters”. The header might include values for naming and specifying a type for a job, etc.; the group section might provide a mechanism for a developer to specify or define how certain parameters of the job can be grouped in a user interface (UI), etc.; and the parameters section may include a listing of the various parameters for a job and their associated values, etc. In some embodiments, a job catalog entry may be its own transport object that can be “shipped” with a report.

FIG. 1is an illustrative schematic depiction100of job catalog entries, including a job catalog entry of the “chain” type105and a job catalog entry of the “simple” type105. A chain type of job catalog entry105refers to a job chain including multiple steps, where each step refers to a job. A simple or basic job110includes a single/one task and includes defining aspects such as parameters and120and groups125to which the job may belong to. Regarding job category entries105and110, each may be a modeled data structure having associated metadata defining the attributes thereof. For example, metadata for job chain105can specify the steps115comprising the job chain and metadata for simple job110can specify defining attributes such as, for example, parameters and groups for the job110.

In some embodiments and aspects, a job chain type of job catalog entry includes a plurality of steps115, where each step may be analogized to one link in a chain. Each step115in the job chain105refers to a simple job type of job catalog entry. Accordingly, one job chain105is associated with many, n, (at least two) simple jobs110. Thus, there is a one-to-many relationship regarding a job chain and the simple jobs it references.

In some aspects, a job chain can be specified (i.e., the particular steps included in the job chain) by referencing (pre-) existing simple jobs. In this manner, a customer or other entity having access to a functionality or interface to define/specify a job chain can link multiple existing simple job catalog entries in a defined order. In some aspects, the entity defining the job chain as such might not need to be knowledgeable of or concerned with, for example, the parameters, code exits, and other aspects of the job chain since such aspects are already defined by the underlying or referenced simple jobs.

In some aspects, a simple job and a job chain can share a common or same metadata model. As such, a system implementing both the job chain and the simple job can propagate metadata maintained for the simple jobs referenced by a job chain to the job chain type of a job catalog entry. In another aspect, propagation of the metadata maintained for the simple jobs referenced by a job chain to the job chain can ensure a level of consistency between different job chains referencing at least some of the same simple jobs. For example, reports generated based on the execution of different job chains that include some of the same simple jobs might exhibit a consistency in the graphical layout and thus, user experience, for a user interacting with those reports.

In some example embodiments, a job chain catalog entry provides a mechanism for a user to rearrange (optionally) how parameters can be rendered on a UI. For example, a user might group some parameters propagated (i.e., inherited) from one or more referenced simple jobs in a configuration different from the grouping of those parameters in the underlying simple jobs. In this manner, for example, a report generated in response to the execution of the job chain may have a UI visualization that differs from reports that might be rendered due to the execution of the simple jobs underlying the job chain.

With reference toFIG. 1, an entity user defining a job chain105selects or otherwise specifies a job catalog entry of the simple job type for each step in the job chain. Parameters, groups, and possibly other aspects and attributes from the referenced simple job type of job catalog entry may be automatically pushed or propagated to the chain job catalog entry.

FIG. 2is an example embodiment of a process200to create a job chain. At operation205, a request to create a job chain is received. In some embodiments, the request is received by a system, device, server, service, application, or other device or apparatus implementing process200or portions thereof. In accordance with some embodiments herein, the job chain to be created is a data structure that will reference a plurality of simple jobs. In some aspects, a graphical user interface can be configured to provide a mechanism for a user (e.g., a developer or other entity) to submit the request to a system, service, or application having functionality to effectuate process200and aspects thereof.

Operation210can include specifying the plurality of simple jobs referenced by the job chain, where each of the simple jobs includes at least one attribute and/or parameter defining an executable task for the simple job. As used herein, an executable task may be any processor-executable instruction or feature, including but not limited to a generation or other processing aspects of a report.

Proceeding to operation215, an order of execution for the plurality of simple jobs referenced by the job chain is specified. Operation215may be implemented in some embodiments by a graphical UI including UI elements to facilitate interfacing with a user to intake selection or specifications of a relative order for the jobs included in the job chain.

In some instances, the specified order may reflect dependencies between the jobs comprising a job chain. For example, a particular job, A, may need to start and/or complete execution before a next particular job, B, can be executed. As an example, the single act/task of sending invoices to customers of an organization may depend on the prior performance of other tasks such as, (1) determining whether ordered goods have shipped, (2) the creation of an invoice for the shipped goods, and (3) determining the mode of transmitting the invoice to be sent (e.g., fax, email, mail, etc.). These (and other) real-world dependencies can be reflected in a job chain by virtue of the specification of the multiple jobs and the particular order of those multiple jobs in a job chain.

In some aspects, the specification of an ordered sequence for the simple jobs comprising a job chain herein can be persisted and reused in the future, by a same or different overall process.

In some aspects, the parameters and other aspects or attributes and characteristics of a simple job that will be or is referenced by a job chain can be specified prior to the referenced simple (or basic) job being specified in a defining process for the job chain. In this manner, parameters and other attributes of the constituent simple jobs can be propagated to the job chain being created. In some instances, the propagation of attributes (e.g., parameters) from the simple job(s) to the job chain can be accomplished automatically without additional input from a user. In some use-cases, a user entity may alter (e.g., re-group) at least some of the attributes (e.g., parameters) from the simple job(s).

Continuing to operation220, process200includes generating an instance of the job chain data structure, wherein the generated job chain references the plurality of simple jobs and inherits at least one attribute (e.g., a parameter, a configuration characteristic, etc.) of each of the plurality of simple jobs. The generated instance of the job chain may be persisted in a data store memory of a database management system, DBMS.

In some aspects, a job chain created by a process herein, including but not limited to process200, can be persisted and used by an application, service, or system. For example, a created job chain can be scheduled for execution by a user via an application jobs scheduling app or service. In some aspects, a job chain created in accordance with some embodiments herein can have an associated label, flag, header, or other feature that indicates that it is a “job chain” to distinguish it from a simple job.

In some aspects herein, processing by a system, service, or device is performed based on tasks, where simple jobs include one task and a job chain includes multiple tasks. In some instances, at least some of the multiple tasks in a job chain can be repeated, none of the multiple tasks in a job chain repeat, and all of the multiple tasks in a job chain are different (i.e., none repeat).

In some instances, one or more simple jobs in a job chain may be executed in parallel, at least partially.

FIG. 3is an illustrative example embodiment of a system architecture for creating, monitoring, and scheduling of a job chain herein. Embodiments of the present disclosure are not limited to the particular architecture300shown inFIG. 3or to a database architecture.

Architecture300includes a platform302supporting and facilitating one or more applications305,307and services (e.g., search service312). Application305may be newly created in accordance with some aspects of the present disclosure to add or enhance a functionality to system300to create a job chain as disclosed herein. System300may include a frontend310that can include one or more of a computer315running a browser and mobile devices such as a tablet320and a mobile phone325that can execute a browser and/or run an application (i.e., and “app”). In some aspects, the app may be separately and independently deployed to one or more of the frontend devices or it may be native to some of those devices. In some embodiments, the devices of the frontend310may differ from the particular devices shown inFIG. 3. Of note, the devices in the frontend310maybe different from each other and demonstrate that system300, including platform302and a backend system represented by a DBMS350may be device-agnostic. Each of the devices in the frontend310may render a UI that is consistently themed for the applications305,307running on platform302. Communication between the frontend devices and platform302may be facilitated by web dispatcher330and mobile platform335, which provide an appropriate communication interface depending on the frontend device.

System300further includes a gateway service345that can provide a mechanism for communicating with DBMS350. In some instances, gateway service345or an instance thereof may be newly created to facilitate and support a creation of a job chain herein.

Applications305,307and services312may include server-side executable instructions (e.g., program code such as, for example, compiled code, scripts, etc.) that can provide functionality to applications executing on frontend devices315,320,325by providing user interfaces thereto, receiving requests (e.g., create a job chain) from those applications and communicating with application305, retrieving data (pre-existing simple jobs and their associated metadata) from a data store of DBMS350based on the requests, processing the data received from DBMS350, storing some of the processed data on DBMS350, providing access to the processed data (e.g., generated instance of a job chain) to application305, and presenting visualizations of the processed data (e.g., the generated job chain) for use by another application. For example, application307may be executed to schedule the execution of the newly generated job chain.

FIG. 4is an example flow diagram400of a process to create a job chain as disclosed in some aspects herein, from a user's point of view. Flow diagram illustrates operational flows between three entities, namely a user405that may be interacting with an application or service via a UI rendered on a processor-enable device, a gateway service410that may facilitate communication with a backend system supporting a processing platform and/or applications and services having some of the functionality disclosed herein, and a design time controller415in the backend. At420, user405sends a request to create a job template to gateway service410that in turn forwards a request to create a job catalog entry of the job chain type to controller415. Design time controller (or another device or system so enabled) creates the job catalog entry of the job chain type.

After creation of the job catalog entry of the job chain type, a visualization of the created job catalog entry of the job chain type can be presented to user405. In reply, user405may select the presented job chain type of job catalog entry via a UI of the device and add a step to the job chain. In accordance with other aspects herein, each step being specified by user405to add to the job chain can be a basic or simple job persisted in a basic catalog, as shown at430. In response to the addition of the step to the job chain at430by user405, a copy of the parameters and other attributes (e.g., groups, sections, etc.) can be sent to the design time controller415from gateway service410. For example, the user may request that the job chain being created include the step of a “Dunning Run”. In this manner, the attributes of the step(s) underlying the job chain can be propagated to the job chain itself.

The controller415may provide, via gateway service410and a UI visualization, an indication or confirmation that the step added at430was actually added to the job chain. In reply thereto, at440the user may select another (or the same) basic job from the job catalog via a UI of their device to add another step (e.g., an “Invoice Run”) to the job chain. In response to the addition of this additional step to the job chain at440, a copy of the parameters and/or other attributes (e.g., groups, sections, etc.) of this second step can be sent to the design time controller415from gateway service410and persisted by the backend of the implementing system.

In some regards, additional and alternate steps may be added to the job chain in a similar manner to those shown inFIG. 4until the job chain being created includes all of the desired steps (i.e., jobs).

FIGS. 5-11each demonstrate some aspect of example user interfaces that may be used to effectuate and/or visualize the creation of a job chain based on underlying simple jobs, in accordance with some aspects herein. An example includingFIGS. 5-11relates to two existing simple jobs that occupy job catalog entries in a job catalog herein. In the present example, the two jobs include a Dunning Run simple job and an Invoice Run simple job, where each includes just one step/task.FIGS. 5-11convey, in some embodiments, an outward view of a displayed user interface or a portion thereof.

FIG. 5is an outward view of a displayed UI500or a portion thereof. The UI500includes a parameter listing for a job catalog entry of the simple job type. In this example, this first simple job, “ZSUPP_1” is an “Invoice Run” and has two parameters505,510with the names as shown.

FIG. 6is an outward view of a displayed UI600or a portion thereof. UI600includes a parameter listing for a job catalog entry of the simple job type. In the present example, this second simple job, “ZSUPP_2” is a “Dunning Run” task and has four parameters605,610,615, and620with the names as shown.

In some instances, a job chain can include a simple or basic job more than once. As such, some embodiments herein can include an alias to identify and differentiate each usage of a simple job in a job chain. All of the “steps” have a unique name and refer to a basic/simple job catalog entry.

In the example ofFIGS. 5-11, an alias is represented as a “step” used in conjunction with the simple job's name to identify each usage of the simple jobs. For example,FIG. 7includes an outward view of a displayed UI700or a portion thereof. UI700includes a tabular parameter listing for a job catalog entry of the job chain type including the simple job “Invoice Run” and the “Dunning Run” simple job. Accordingly, UI700lists parameters for the “Dunning Run” job (i.e., “ZSUPP_2”) at715,720,725, and730and lists parameters for the “Invoice Run” simple job (i.e., “ZSUPP_1”) at735and740. UI700further includes columns for listing the source job catalog at702, the source job catalog parameter name (if any) at704, and the parameter name used to fill a parameter (if needed) as shown at706and708.

Referring toFIG. 7still, it is seen that the use of aliases in the present example results in compound parameter names. The parameter names701include a name and a step. For example, the parameter listed at715has the name of “P_BUY_D, Step 1” and the parameter listed at735has the name of “P_BUY_D, Step 2”. The addition of the step designator differentiates each usage of the “P_BUY_D” from the other.

In the example ofFIGS. 5-11, the basic or simple job catalog ZSUPP_1 and ZSUPP_2 both have a parameter “P_BUY_D” and “S_PLANT”. In some embodiments, a default behaviour of a system is to add all attributes and/or parameters of the basic job catalog to the job chain catalog.

In some use-cases, it may be the case that the same attributes and/or parameters from different catalog entries are filled differently (i.e., have different values), but in general it may be assumed that they should have the same values. For some such cases, the present disclosure offers a mechanism to define a parameter as depending on another parameter. This aspect is seen in UI700at711where the name706and step708can be specified for a parameter depending on another parameter.

In the example ofFIG. 7, the job chain parameters “P_BUY_D 2” (735) and “S_PLANT 2” (740) depend from “P_BUY_D 1” and “S_PLANT 1” and this dependency is specified at745and750. In some regards, this means that on the UI the parameters “P_BUY_D 2” and “S_PLANT 2” will be hidden on a parameter screen UI and the system will automatically distribute the parameter values according to the specified dependency.

FIGS. 8-11more particularly relate to a parameter value distribution process in some embodiments herein.FIG. 8includes an outward view of a displayed UI800or a portion thereof. UI800includes a tabular parameter listing for parameters named as indicated at805and810and their corresponding values are shown at815. The values in the table inFIG. 8can be specified by a user interacting with UI800.

FIG. 9includes an outward view of a displayed UI900or a portion thereof. UI900includes a tabular parameter listing for the parameters and their corresponding values for a job chain. The table listed inFIG. 9may result from the creation of a job chain (e.g., in reply to an invocation or triggering by a user, etc.). In particular, the parameter-value listing of UI900corresponds to the job chain parameter listing shown inFIG. 7in UI700. As seen in UI900, the system distributes the parameter values to the dependent job chain parameters as specified in the table ofFIG. 7.

FIGS. 10 and 11illustrate how an implementing system might distribute the job parameter values from the job chain to the underlying basic/simple job catalogs, in light of the values and dependencies specified by the user in the present example.

In some aspects, after the parameter vales are distributed to the underlying job catalog entries as shown inFIGS. 10 and 11in UIs1000and1100, a system can create, for example, report variants based thereon, invoke a job scheduling framework/application to use the now defined values, and other processes, applications, and use-cases.

FIG. 12is a block diagram of apparatus1200according to some embodiments. Apparatus1200may comprise a computing apparatus and may execute program code to perform any of the functions described herein. Apparatus1200may comprise an implementation of server supporting an application (e.g.,305,307), DBMS350, and data store ofFIG. 1in some embodiments. Apparatus1200may include other unshown elements according to some embodiments.

Apparatus1200includes processor1205operatively coupled to communication device1220, data storage device1230, one or more input devices1210, one or more output devices1220and memory1225. Communication device1215may facilitate communication with external devices, such as a reporting client, or a data storage device. Input device(s)1210may comprise, for example, a keyboard, a keypad, a mouse or other pointing device, a microphone, knob or a switch, an infra-red (IR) port, a docking station, and/or a touch screen. Input device(s)1210may be used, for example, to enter information into apparatus1200. Output device(s)1220may comprise, for example, a display (e.g., a display screen) a speaker, and/or a printer.

Data storage device1230may comprise any appropriate persistent storage device, including combinations of magnetic storage devices (e.g., magnetic tape, hard disk drives and flash memory), optical storage devices, Read Only Memory (ROM) devices, etc., while memory1225may comprise Random Access Memory (RAM), Storage Class Memory (SCM) or any other fast-access memory.

Services1235, application1240, and DBMS1245may comprise program code executed by processor1205to cause apparatus1200to perform any one or more of the processes described herein. Embodiments are not limited to execution of these processes by a single apparatus.

Data1250and metadata1250(either cached or a full database) may be stored in volatile memory such as memory1225. Metadata1250may include information regarding parameters, groups, sections, and other attributes of simple jobs and job chains. Data storage device1230may also store data and other program code and instructions for providing additional functionality and/or which are necessary for operation of apparatus1200, such as device drivers, operating system files, etc.