Patent Description:
Strategic sourcing can be performed by a company to monitor and evaluate sourcing strategies. Sourcing strategies can include determining from which entity to purchase items that need to be procured. Strategic sourcing can include supply chain management, supplier development, contract negotiation, and outsourcing evaluation. <CIT> describes systems, methods, and computer-readable media for event sourcing datastores. Events are sent to an event sourcing datastore (ESDS) from an external service, and the events are appended to an event log. The ESDS maintains the event log in one table and the events are automatically aggregated via streaming. The ESDS is linearly scalable, and enforces uniqueness, consistency, and user-defined constraints when appending events to the event log. The aggregate state is computed asynchronously and transparently cached, which provides increased read throughput and reduced latency.

Particular embodiments are the subject of the dependent claims.

The present disclosure is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements.

The description that follows discusses illustrative systems, methods, techniques, instruction sequences, and computing machine program products. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide an understanding of various example embodiments of the present subject matter. It will be evident, however, to those skilled in the art, that various example embodiments of the present subject matter may be practiced without these specific details.

Organizations may wish to procure item(s) for the organization. For example, an organization may wish to find a supplier who can provide the item(s) at the lowest price. Other factors can influence selection of a supplier, such as past interactions, overall reputation, delivery time factors, etc. Strategic sourcing can be a process for trying to find a best supplier for the organization for a set of one or more items that the organization wants to procure. After performing the strategic analysis, a supplier can be selected and awarded a sourcing opportunity.

An input to strategic sourcing can be a sourcing event that includes a list of line item(s) that the organization wants to procure. Line items for a sourcing event can be defined using a user interface that has fixed fields into which values for line items can be added. The data pertaining to the sourcing event is then stored in a relational database for later retrieval for subsequent sourcing events and/or analysis.

A technical issue, however, is encountered for sourcing events that have a large amount of data. Users expect for events to be processed within <NUM> second or less, and sourcing events with large amounts of data (e.g., over <NUM> line items and/or over <NUM> participants) are not able to be processed within that <NUM> second limit. This is because a server cache will hold up events in memory. Additionally, the fetching of sourcing event data with large amounts of data would also be time consuming. As a result, the fixed field graphical user interface typically will limit input sourcing events to "standard-size"-only, namely sourcing events with fewer than <NUM> line items. Large sourcing events, known as Large Line Item (LLI) events, are handled separately via spreadsheet input, and are not stored in the same database as the standard event data, limiting reporting and analysis features.

There is risk, however, in changing the existing core sourcing application, as most events (greater than <NUM>%) are of standard size as opposed to LLI, and the existing core sourcing application is quite stable and effective for such standard-size events.

In an example embodiment, a scalable solution is provided that identifies sourcing events that are large line item events and reroutes requests for operations related to such events to a specialized content service. The specialized content service authenticates the requests and causes data pertaining to the large line item events to be stored in and/or retrieved from a document database for LLI event processing. The result is that operations for LLI events are able to be processed much faster than in prior art solutions.

In sourcing, an event proceeds through multiple processing steps, starting with event creation by organizations and ending with a selection to "winning" suppliers. At each stage of the process, the event has a defined status which determines the actions a user can take. <FIG> is a diagram illustrating a lifecycle <NUM> of an LLI event, in accordance with an example embodiment. A creation process <NUM> involves the creation of a draft LLI event <NUM>, which can then be published. A monitoring process <NUM> involves the previewing <NUM> of a bidding process as well as event <NUM> where the LLI event is open for bidding. Once bidding time is over, an evaluation process <NUM> takes over and a pending selection of a "winner" is made <NUM>. Once the bid has been awarded, a completed event <NUM> occurs, or if at any point during the monitoring process <NUM> or evaluation process <NUM> the bidding is cancelled, a cancelled event <NUM> occurs.

There are functionalities at each of these event lifecycle stages where large amounts of data must be handled within defined service level agreements (SLAs). For example, an expected SLA for a content upload with <NUM>,<NUM> line items may be <NUM> seconds, as may be an expected SLA for a bid upload with <NUM>,<NUM> line items. Report generation with <NUM> supplier bids may have an expected SLA of <NUM> minutes, with concurrent processing of <NUM> supplier bids having an expected SLA of <NUM> minutes.

<FIG> is a block diagram illustrating a system <NUM> for processing LLI events in accordance with an example embodiment. A graphical user interface <NUM> may permit users to enter fixed line items for a sourcing event and/or request reporting on a sourcing event. It should be noted that the graphical user interface <NUM> displayed here may be a server-based graphical user interface, which may communicate with a client device running a client-side portion of a sourcing application <NUM> to perform the various graphical user interface operations requested. This, however, is not mandatory. In other example embodiments, the graphical user interface <NUM> may be client-based, and thus may, for example, be contained within the client-side portion of the sourcing application <NUM>.

A user can use the sourcing application <NUM> to create a sourcing event. A sourcing event can be an auction request, a request for information (RFI), a request for a proposal, or a request for quotation (which can all generically be referred to as RFX (e.g., request for "X")). The sourcing event can be sent from the graphical user interface <NUM> to the application core <NUM>.

The application core <NUM> may receive an event request from the graphical user interface <NUM>. Notably, this event request could be a request to provide or utilize data from any of the event lifecycle stages, such as the stages described above with respect to <FIG>. Also notably, the event requests may correspond to standard events or LLI events. In an example embodiment, a standard event is defined as an event involving <NUM> or fewer line items, while a LLE event is defined as an event involving more than <NUM> line items. This threshold, however, can be different depending upon implementation. For purposes of this disclosure, it is enough that the application core <NUM> know how to differentiate between a standard event and an LLI event. This is because LLI event processing is going to be abstracted from the integration component into a microservice-based stack that is backed by a document database.

In an example embodiment, the application core <NUM> may be an S/<NUM> Hana™ cloud, from SAP SE of Frankfurt, Germany. S/<NUM> Hana™ is a modular cloud enterprise resource processing (ERP) software running with an in-memory database. An in-memory database (also known as an in-memory database management system) is a type of database management system that primarily relies on main memory for computer data storage. It is contrasted with database management systems that employ a disk storage mechanism. In-memory databases are traditionally faster than disk storage databases because disk access is slower than memory access.

The core <NUM> determines whether event request corresponds to an LLI event or a standard event. If it corresponds to an LLI event, then the request is rerouted to a content service <NUM>, which is a microservice-based stack that is backed by a document database. More particularly, a tenant authentication component <NUM> within the content service <NUM> acts to verify the tenant for the LLI request, by sending an OAuth token to OAuth service <NUM> for verification. Once verified, realm information is sent from the OAuth service <NUM> to the tenant authentication component <NUM>, which then uses the realm information to fetch a tenant identification.

The tenant authentication component <NUM> then indicates the LLI request has been validated, and a content storage component <NUM> forwards the LLI request to a representational state transfer (REST) Application program Interface (API) <NUM>, which then uses a tenant-specific in-memory database instance <NUM> (identified using the tenant identification) to connect to a tenant schema <NUM>. The tenant schema <NUM> identifies content/bid data in a document database <NUM> as well as metadata in a relational database <NUM>. This allows the REST API <NUM> to perform whatever operations are necessary to satisfy the LLI request using a combination of content/bid data and metadata. These operations may include Create, Read, Update and Delete (CRUD) operations.

Notably, the line item data itself are stored in the document database <NUM>. There are two types of information provided for line items for an event: one from a procuring organization and another from supplier organizations who provide the bids for the line items. Thus, the data is semi-structured in nature, and varies on the terms provided by the procuring organization and the bid values provided by the suppliers. Since faster reads and writes are needed for the large amount of data in LLI events, a document database <NUM> is used instead of relying on the relational database <NUM> for such storage.

A document database is a non-relational database that stores information as documents (as opposed to as in tables, as in a relational database). A document typically stores information about one object, and any of its related metadata, as a record in the document database <NUM>. Documents store data in field-value pairs. These values can be a variety of types and structures, including strings, numbers, dates, arrays, or objects. Documents can be stored in a variety of formats, although in one example embodiment the documents are stored as Javascript™ Object Notation (JSON) files. The documents may be grouped into collections in the document database <NUM>.

If report generation is needed as part of the LLI request, then a report generation component can generate the report. Furthermore, content service <NUM> may also communicate data retrieved via the LLI requests to one or more other applications, such as an optimization workbench (OWB) <NUM>, which can perform bid analysis and optimization scenarios.

<FIG> is a block diagram illustrating a data model <NUM> used by the document database <NUM>, in an example embodiment. Here, an event submission event <NUM> may use realm information <NUM> and event metadata <NUM> from tables and create a document for each event term in collection <NUM>. An event published event <NUM> may use payload information <NUM> and spreadsheet content data <NUM> to create a document for each event item in collection <NUM>, as well as create a document for each event participant in collection <NUM>, and a document for each event item value in collection <NUM>. A bids submission event <NUM> may use spreadsheet bid data <NUM> to create a document for each event item value in collection <NUM>. A content bid generation event <NUM> uses spreadsheet content generation data <NUM> and spreadsheet bid generation data <NUM> to create a document for each event item value in collection <NUM>. Finally, an event moved to pending selection event <NUM> may use spreadsheet bid rank data <NUM> and event report data <NUM> to create a document for each event rollup item value in collection <NUM>.

When an LLI event is received, it may be in the form of a large spreadsheet with rows representing each line item. Repetitive tasks like validation of each spreadsheet row, processing of each spreadsheet row, and transforming each spreadsheet row into a JSON document so that it can be saved in a document database may be performed concurrently (parallel processing) using, for example, a concurrent processing framework, such as Akka™. Akka™ is a toolkit and runtime that simplifies the construction of concurrent and distributed applications on a virtual machine. It focuses on actor-based concurrency. Actor-based concurrency treats an actor as the universal primate of concurrent computation. In response to a message it receives, an actor can make local decisions, create more actors, send more messages, and determine how to respond to the next message received. Actors may also modify their own private state, but can only affect each other indirectly through messaging (removing the need for lock-based synchronization).

In an example embodiment, there are several concurrent threads in round robin fashion for achieving the above functionalities.

In an example embodiment, communications among the various components are performed asynchronously, via a message broker, rather than synchronously.

As mentioned above, the graphical user interface <NUM> may be implemented at server-side. For further efficiency, the graphical user interface <NUM> may utilize cursor-based pagination. Here, line items are on the vertical access and bid values are on the horizontal access, and a user may scroll vertically or horizontally using a cursor.

<FIG> is a screen capture illustrating a graphical user interface <NUM> for adding line items to an LLI event, in accordance with an example embodiment. Here, the graphical user interface <NUM> provides the ability for a user to enter a line item by selecting an "add" button <NUM>. Additionally, a term may be added to a line item by selecting an "add term" button <NUM>.

<FIG> is a screen capture illustrating a graphical user interface <NUM> for adding terms to a line item of an LLI event, in accordance with an example embodiment. Here, the graphical user interface <NUM> provides the ability for a user to enter a name for a term in name field <NUM>, as well as various aspects of the term in various drop downs <NUM>, <NUM>, <NUM> and buttons <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>.

<FIG> is a screen capture illustrating a graphical user interface <NUM> for adding line item information in accordance with an example embodiment. Here, the graphical user interface <NUM> provides the ability for a user to enter a name for a line item in name field <NUM>, as well as a description <NUM>, commodity <NUM>, and region <NUM>. Furthermore, checkboxes <NUM> and <NUM> allow the user to indicate whether a response is required and/or whether the line item is visible to participants, respectively. Additionally, initial values for various terms may be entered in fields <NUM>, <NUM>, and <NUM>.

<FIG> is a screen capture illustrating a graphical user interface <NUM> for publishing a created report, in accordance with an example embodiment. Here, the graphical user interface <NUM> permits a user to publish a created LLI event by pressing a publish button <NUM>.

<FIG> is a screen capture illustrating a graphical user interface <NUM> for viewing a report about data recorded via an LLI event, in accordance with an example embodiment. Here, the report may include a graph <NUM> of supplier participation, an indication <NUM> of how long the event has left (the event here being bidding), and an indication <NUM> of total item coverage. Other metrics may also be displayed in this graphical user interface <NUM>, but are not pictured here for succinctness. Notably, all of this information may be retrieved from standard events (stored in a relational database) and/or LLI events (stored in a document database). As such, this graphical user interface <NUM> essentially integrates with existing graphical user interfaces that permit reports only from standard events (stored in a relational database) and not LLI events.

<FIG> is a flow diagram illustrating a method <NUM> of handling a request for an operation corresponding to an LLI event, in accordance with an example embodiment. At operation <NUM>, a request for an operation for a large line item (LLI) event is received from an application core, such as a sourcing application core. The request has been rerouted from the application core based on a determination that a request for an operation for an event corresponds to a LLI event, in accordance with a threshold defined for a large line item event at the application core. That threshold may specify a particular number of line items for an event, such as <NUM>, beyond which the event is considered a LLI event rather than a standard event.

At operation <NUM>, an authorization token corresponding to the request for the operation for the LLI event is sent to an authorization service. At operation <NUM>, realm information is received from the authorization service. The realm information may include a tenant identification. At operation <NUM>, the tenant identification is used to access a REST API to obtain a tenant schema in an instance of an in-memory database corresponding to the tenant identification. The in-memory database contains both a non-relational document database and a relational database.

At operation <NUM>, the operation is executed on one or more documents corresponding to the LLI event, the one or more documents stored in a collection in the non-relational document database. At operation <NUM>, results of the operation are received from the non-relational document database. At operation <NUM>, the results are sent to the application core for reporting to a user via a graphical user interface.

<FIG> is a block diagram <NUM> illustrating a software architecture <NUM>, which can be installed on any one or more of the devices described above. <FIG> is merely a non-limiting example of a software architecture, and it will be appreciated that many other architectures can be implemented to facilitate the functionality described herein. In various embodiments, the software architecture <NUM> is implemented by hardware such as a machine <NUM> of <FIG> that includes processors <NUM>, memory <NUM>, and input/output (I/O) components <NUM>. In this example architecture, the software architecture <NUM> of <FIG> can be conceptualized as a stack of layers where each layer may provide a particular functionality. For example, the software architecture <NUM> includes layers such as an operating system <NUM>, libraries <NUM>, frameworks <NUM>, and applications <NUM>. Operationally, the applications <NUM> invoke Application Program Interface (API) calls <NUM> through the software stack and receive messages <NUM> in response to the API calls <NUM>, consistent with some embodiments.

In various implementations, the operating system <NUM> manages hardware resources and provides common services. The operating system <NUM> includes, for example, a kernel <NUM>, services <NUM>, and drivers <NUM>. The kernel <NUM> acts as an abstraction layer between the hardware and the other software layers, consistent with some embodiments. For example, the kernel <NUM> provides memory management, processor management (e.g., scheduling), component management, networking, and security settings, among other functionalities. The services <NUM> can provide other common services for the other software layers. The drivers <NUM> are responsible for controlling or interfacing with the underlying hardware. For instance, the drivers <NUM> can include display drivers, camera drivers, BLUETOOTH® or BLUETOOTH® Low-Energy drivers, flash memory drivers, serial communication drivers (e.g., Universal Serial Bus (USB) drivers), Wi-Fi® drivers, audio drivers, power management drivers, and so forth.

In some embodiments, the libraries <NUM> provide a low-level common infrastructure utilized by the applications <NUM>. The libraries <NUM> can include system libraries <NUM> (e.g., C standard library) that can provide functions such as memory allocation functions, string manipulation functions, mathematic functions, and the like. In addition, the libraries <NUM> can include API libraries <NUM> such as media libraries (e.g., libraries to support presentation and manipulation of various media formats such as Moving Picture Experts Group-<NUM> (MPEG4), Advanced Video Coding (H. <NUM> or AVC), Moving Picture Experts Group Layer-<NUM> (MP3), Advanced Audio Coding (AAC), Adaptive Multi-Rate (AMR) audio codec, Joint Photographic Experts Group (JPEG or JPG), or Portable Network Graphics (PNG)), graphics libraries (e.g., an OpenGL framework used to render in two-dimensional (2D) and three-dimensional (3D) in a graphic context on a display), database libraries (e.g., SQLite to provide various relational database functions), web libraries (e.g., WebKit to provide web browsing functionality), and the like. The libraries <NUM> can also include a wide variety of other libraries <NUM> to provide many other APIs to the applications <NUM>.

The frameworks <NUM> provide a high-level common infrastructure that can be utilized by the applications <NUM>. For example, the frameworks <NUM> provide various graphical user interface (GUI) functions, high-level resource management, high-level location services, and so forth. The frameworks <NUM> can provide a broad spectrum of other APIs that can be utilized by the applications <NUM>, some of which may be specific to a particular operating system <NUM> or platform.

In an example embodiment, the applications <NUM> include a home application <NUM>, a contacts application <NUM>, a browser application <NUM>, a book reader application <NUM>, a location application <NUM>, a media application <NUM>, a messaging application <NUM>, a game application <NUM>, and a broad assortment of other applications, such as a third-party application <NUM>. The applications <NUM> are programs that execute functions defined in the programs. Various programming languages can be employed to create one or more of the applications <NUM>, structured in a variety of manners, such as object-oriented programming languages (e.g., Objective-C, Java, or C++) or procedural programming languages (e.g., C or assembly language). In a specific example, the third-party application <NUM> (e.g., an application developed using the ANDROID™ or IOS™ software development kit (SDK) by an entity other than the vendor of the particular platform) may be mobile software running on a mobile operating system such as IOS™ ANDROID™, WINDOWS® Phone, or another mobile operating system. In this example, the third-party application <NUM> can invoke the API calls <NUM> provided by the operating system <NUM> to facilitate functionality described herein.

<FIG> illustrates a diagrammatic representation of a machine <NUM> in the form of a computer system within which a set of instructions may be executed for causing the machine <NUM> to perform any one or more of the methodologies discussed herein. Specifically, <FIG> shows a diagrammatic representation of the machine <NUM> in the example form of a computer system, within which instructions <NUM> (e.g., software, a program, an application, an applet, an app, or other executable code) for causing the machine <NUM> to perform any one or more of the methodologies discussed herein may be executed. For example, the instructions <NUM> may cause the machine <NUM> to execute the method of <FIG>. Additionally, or alternatively, the instructions <NUM> may implement <FIG> and so forth. The instructions <NUM> transform the general, non-programmed machine <NUM> into a particular machine <NUM> programmed to carry out the described and illustrated functions in the manner described. In alternative embodiments, the machine <NUM> operates as a standalone device or may be coupled (e.g., networked) to other machines. In a networked deployment, the machine <NUM> may operate in the capacity of a server machine or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine <NUM> may comprise, but not be limited to, a server computer, a client computer, a personal computer (PC), a tablet computer, a laptop computer, a netbook, a set-top box (STB), a personal digital assistant (PDA), an entertainment media system, a cellular telephone, a smart phone, a mobile device, a wearable device (e.g., a smart watch), a smart home device (e.g., a smart appliance), other smart devices, a web appliance, a network router, a network switch, a network bridge, or any machine capable of executing the instructions <NUM>, sequentially or otherwise, that specify actions to be taken by the machine <NUM>. Further, while only a single machine <NUM> is illustrated, the term "machine" shall also be taken to include a collection of machines <NUM> that individually or jointly execute the instructions <NUM> to perform any one or more of the methodologies discussed herein.

The machine <NUM> may include processors <NUM>, memory <NUM>, and I/O components <NUM>, which may be configured to communicate with each other such as via a bus <NUM>. In an example embodiment, the processors <NUM> (e.g., a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a radio-frequency integrated circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, a processor <NUM> and a processor <NUM> that may execute the instructions <NUM>. The term "processor" is intended to include multi-core processors that may comprise two or more independent processors (sometimes referred to as "cores") that may execute instructions <NUM> contemporaneously. Although <FIG> shows multiple processors <NUM>, the machine <NUM> may include a single processor <NUM> with a single core, a single processor <NUM> with multiple cores (e.g., a multi-core processor <NUM>), multiple processors <NUM>, <NUM> with a single core, multiple processors <NUM>, <NUM> with multiple cores, or any combination thereof.

The memory <NUM> may include a main memory <NUM>, a static memory <NUM>, and a storage unit <NUM>, each accessible to the processors <NUM> such as via the bus <NUM>. The main memory <NUM>, the static memory <NUM>, and the storage unit <NUM> store the instructions <NUM> embodying any one or more of the methodologies or functions described herein. The instructions <NUM> may also reside, completely or partially, within the main memory <NUM>, within the static memory <NUM>, within the storage unit <NUM>, within at least one of the processors <NUM> (e.g., within the processor's cache memory), or any suitable combination thereof, during execution thereof by the machine <NUM>.

The I/O components <NUM> may include a wide variety of components to receive input, provide output, produce output, transmit information, exchange information, capture measurements, and so on. The specific I/O components <NUM> that are included in a particular machine will depend on the type of machine. For example, portable machines such as mobile phones will likely include a touch input device or other such input mechanisms, while a headless server machine will likely not include such a touch input device. It will be appreciated that the I/O components <NUM> may include many other components that are not shown in <FIG>. The I/O components <NUM> are grouped according to functionality merely for simplifying the following discussion, and the grouping is in no way limiting. In various example embodiments, the I/O components <NUM> may include output components <NUM> and input components <NUM>. The output components <NUM> may include visual components (e.g., a display such as a plasma display panel (PDP), a light-emitting diode (LED) display, a liquid crystal display (LCD), a projector, or a cathode ray tube (CRT)), acoustic components (e.g., speakers), haptic components (e.g., a vibratory motor, resistance mechanisms), other signal generators, and so forth. The input components <NUM> may include alphanumeric input components (e.g., a keyboard, a touch screen configured to receive alphanumeric input, a photo-optical keyboard, or other alphanumeric input components), point-based input components (e.g., a mouse, a touchpad, a trackball, a joystick, a motion sensor, or another pointing instrument), tactile input components (e.g., a physical button, a touch screen that provides location and/or force of touches or touch gestures, or other tactile input components), audio input components (e.g., a microphone), and the like.

In further example embodiments, the I/O components <NUM> may include biometric components <NUM>, motion components <NUM>, environmental components <NUM>, or position components <NUM>, among a wide array of other components. For example, the biometric components <NUM> may include components to detect expressions (e.g., hand expressions, facial expressions, vocal expressions, body gestures, or eye tracking), measure biosignals (e.g., blood pressure, heart rate, body temperature, perspiration, or brain waves), identify a person (e.g., voice identification, retinal identification, facial identification, fingerprint identification, or electroencephalogram-based identification), and the like. The motion components <NUM> may include acceleration sensor components (e.g., accelerometer), gravitation sensor components, rotation sensor components (e.g., gyroscope), and so forth. The environmental components <NUM> may include, for example, illumination sensor components (e.g., photometer), temperature sensor components (e.g., one or more thermometers that detect ambient temperature), humidity sensor components, pressure sensor components (e.g., barometer), acoustic sensor components (e.g., one or more microphones that detect background noise), proximity sensor components (e.g., infrared sensors that detect nearby objects), gas sensors (e.g., gas detection sensors to detect concentrations of hazardous gases for safety or to measure pollutants in the atmosphere), or other components that may provide indications, measurements, or signals corresponding to a surrounding physical environment. The position components <NUM> may include location sensor components (e.g., a Global Positioning System (GPS) receiver component), altitude sensor components (e.g., altimeters or barometers that detect air pressure from which altitude may be derived), orientation sensor components (e.g., magnetometers), and the like.

Communication may be implemented using a wide variety of technologies. The I/O components <NUM> may include communication components <NUM> operable to couple the machine <NUM> to a network <NUM> or devices <NUM> via a coupling <NUM> and a coupling <NUM>, respectively. For example, the communication components <NUM> may include a network interface component or another suitable device to interface with the network <NUM>. In further examples, the communication components <NUM> may include wired communication components, wireless communication components, cellular communication components, Near Field Communication (NFC) components, Bluetooth® components (e.g., Bluetooth® Low Energy), Wi-Fi® components, and other communication components to provide communication via other modalities. The devices <NUM> may be another machine or any of a wide variety of peripheral devices (e.g., coupled via a USB).

For example, the communication components <NUM> may include radio-frequency identification (RFID) tag reader components, NFC smart tag detection components, optical reader components (e.g., an optical sensor to detect one-dimensional bar codes such as Universal Product Code (UPC) bar code, multi-dimensional bar codes such as QR code, Aztec code, Data Matrix, Dataglyph, MaxiCode, PDF417, Ultra Code, UCC RSS-2D bar code, and other optical codes), or acoustic detection components (e.g., microphones to identify tagged audio signals).

The various memories (i.e., <NUM>, <NUM>, <NUM>, and/or memory of the processor(s) <NUM>) and/or the storage unit <NUM> may store one or more sets of instructions <NUM> and data structures (e.g., software) embodying or utilized by any one or more of the methodologies or functions described herein. These instructions (e.g., the instructions <NUM>), when executed by the processor(s) <NUM>, cause various operations to implement the disclosed embodiments.

As used herein, the terms "machine-storage medium," "device-storage medium," and "computer-storage medium" mean the same thing and may be used interchangeably. The terms refer to single or multiple storage devices and/or media (e.g., a centralized or distributed database, and/or associated caches and servers) that store executable instructions and/or data. The terms shall accordingly be taken to include, but not be limited to, solid-state memories, and optical and magnetic media, including memory internal or external to processors. Specific examples of machine-storage media, computer-storage media, and/or device-storage media include nonvolatile memory, including by way of example semiconductor memory devices, e.g., erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), field-programmable gate array (FPGA), and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The terms "machine-storage media," "computer-storage media," and "device-storage media" specifically exclude carrier waves, modulated data signals, and other such media, at least some of which are covered under the term "signal medium" discussed below.

In various example embodiments, one or more portions of the network <NUM> may be an ad hoc network, an intranet, an extranet, a virtual private network (VPN), a local-area network (LAN), a wireless LAN (WLAN), a wide-area network (WAN), a wireless WAN (WWAN), a metropolitan-area network (MAN), the Internet, a portion of the Internet, a portion of the public switched telephone network (PSTN), a plain old telephone service (POTS) network, a cellular telephone network, a wireless network, a Wi-Fi® network, another type of network, or a combination of two or more such networks. For example, the network <NUM> or a portion of the network <NUM> may include a wireless or cellular network, and the coupling <NUM> may be a Code Division Multiple Access (CDMA) connection, a Global System for Mobile communications (GSM) connection, or another type of cellular or wireless coupling. In this example, the coupling <NUM> may implement any of a variety of types of data transfer technology, such as Single Carrier Radio Transmission Technology (1xRTT), Evolution-Data Optimized (EVDO) technology, General Packet Radio Service (GPRS) technology, Enhanced Data rates for GSM Evolution (EDGE) technology, third Generation Partnership Project (3GPP) including <NUM>, fourth generation wireless (<NUM>) networks, Universal Mobile Telecommunications System (UMTS), High-Speed Packet Access (HSPA), Worldwide Interoperability for Microwave Access (WiMAX), Long-Term Evolution (LTE) standard, others defined by various standard-setting organizations, other long-range protocols, or other data transfer technology.

The instructions <NUM> may be transmitted or received over the network <NUM> using a transmission medium via a network interface device (e.g., a network interface component included in the communication components <NUM>) and utilizing any one of several well-known transfer protocols (e.g., HTTP). Similarly, the instructions <NUM> may be transmitted or received using a transmission medium via the coupling <NUM> (e.g., a peer-to-peer coupling) to the devices <NUM>. The terms "transmission medium" and "signal medium" mean the same thing and may be used interchangeably in this disclosure. The terms "transmission medium" and "signal medium" shall be taken to include any intangible medium that is capable of storing, encoding, or carrying the instructions <NUM> for execution by the machine <NUM>, and include digital or analog communications signals or other intangible media to facilitate communication of such software. Hence, the terms "transmission medium" and "signal medium" shall be taken to include any form of modulated data signal, carrier wave, and so forth.

Claim 1:
A system (<NUM>) comprising:
at least one hardware processor; and
a computer-readable medium storing instructions that, when executed by the at least one hardware processor, cause the at least one hardware processor to perform operations comprising:
receiving (<NUM>), from an application core (<NUM>), a request for operations related to a sourcing event that includes a list of line items, the sourcing event being created by a user, wherein the request has been rerouted from the application core (<NUM>) based on a determination that the request corresponds to a large line item (LLI) event rather than a standard event, in accordance with a threshold defined for a large line item event at the application core (<NUM>), wherein the LLI event is defined as an event involving line items being more than the threshold indicating a number of line items in a sourcing event;
transforming each line item into a Javascript Object Notation (JSON) document to be saved in a document database (<NUM>) concurrently using a concurrent processing framework;
executing (<NUM>) the operations on the documents corresponding to the LLI event, the documents stored as the JSON documents [<NUM>] in a collection (<NUM>; <NUM>-<NUM>; <NUM>) in the non-relational document database (<NUM>), wherein the executing (<NUM>) the operations includes executing the operations on the plurality of line items within the LLI event simultaneously via multiple concurrent threads, the operations including one or more of Create, Read, Update and Delete (CRUD) operations;
receiving (<NUM>) results of the operations from the non-relational document database (<NUM>); and
sending (<NUM>) the results to the application core (<NUM>) for reporting on the sourcing event to the user via a graphical user interface (<NUM>; <NUM>-<NUM>).