| Oracle® Retail Bulk Data Integration Cloud Service Implementation Guide Release 19.1.000 F31810-01 |
|
 Previous |
 Next |
| Oracle® Retail Bulk Data Integration Cloud Service Implementation Guide Release 19.1.000 F31810-01 |
|
Previous |
Next |
Bulk Data Integration (BDI) is the Oracle Retail Enterprise Integration Infrastructure product designed to address the complexities of the movement of bulk data between Oracle Retail applications and third-party applications. BDI is designed to provide the bulk data integration to meet the modern needs of cloud and on-premise movement of large data sets in the deployments of the Oracle Retail applications and fully support both on-premise configurations and on-cloud configurations in a hybrid cloud-premise deployment.
There is no one integration approach that addresses all criteria equally well. Therefore, multiple approaches for integrating applications have evolved over time. Oracle Retail has focused on three main integration styles:
Asynchronous JMS Pub/Sub Fire-and-Forget (Retail Integration Bus - RIB)
Request/Response (Retail Service Backbone - RSB)
Bulk Data Integration - BDI
Batch (Bulk) data is still a predominant integration style within Oracle Retail and its Customers.
The movement of bulk data remains important because some work is best suited to being performed in bulk. Batch processing was there in the early days; it's still here today; and it will still be here tomorrow. What has changed is the approach to batch processing.
Batch processing is typified by bulk-oriented, non-interactive, background execution. Frequently long running, it may be data or computationally intensive, executed sequentially or in parallel, and may be initiated through various invocation models, including ad hoc, scheduled, and on-demand.
Batch applications have common requirements including logging, checkpoint, and parallelization. Batch workloads have common requirements such as operational control, which allow for initiation of, and interaction with, batch instances; such interactions include stop and restart.
BDI is the latest Oracle Retail Integration product to be released to productize Oracle Retail bulk data flows for delivery to customers to meet these requirements, and provide the tooling that is required to automate the creation and packaging of the configurations and to manage the full life cycle.
Oracle Retail now has integration products designed and built to satisfy all three of the integration styles used by our customers today.
BDI, such as RIB and RSB, relies on industry standards and specifications and leverages the features of the WebLogic Application Server.
In 2011, a working group was formed to study and design an open standard for Java batch processing. Representatives from many companies, including Oracle, developed a draft standard. The initial release of the standard was released in 2013. The standard, known as 352, is now included as part of the Java EE 7 open standard.
BDI is designed and built on these Java EE 7 and Java Batch (JSR 352) specifications and standards.
Java Platform Enterprise Edition (Java EE) is an umbrella standard for Java's enterprise computing facilities. It bundles together technologies for a complete enterprise-class server-side development and deployment platform in java.
Java EE specification includes several other API specifications, such as JDBC, RMI, Transaction, JMS, Web Services, XML, Persistence, mail, and others and defines how to coordinate among them. Java EE also features some specifications unique to enterprise computing. These include Enterprise JavaBeans (EJB), servlets, portlets, Java Server Pages (JSP), Java Server Faces (JSF) and several Web service technologies.
A Java EE application server manages transactions, security, scalability, concurrency, pooling, and management of the EJB/Web components that are deployed to it. This frees the developers to concentrate more on the business logic/problem of the components rather than spending time building scalable, robust infrastructure on which to run on.
JSR 352 is a Java specification for building, deploying, and running batch applications. Batch is an industry metaphor for background bulk processing. A myriad business processes depend on batch processing and demand powerful standards-based facilities for enabling this essential workload type.
JSR 352 specifies the layers, components and technical services commonly found in robust, maintainable systems used to address the creation of simple to complex batch applications.
JSR 352 addresses three critical concerns: a batch programming model, a job specification language, and a batch runtime. This constitutes a separation of concerns.
Application developers have clear, reusable interfaces for constructing batch style applications
Job writers have a powerful expression language for how to execute the steps of a batch execution
Solution integrators have a runtime API for initiating and controlling batch execution
JSR 352 defines a Job Specification Language (JSL) to define batch jobs, a set of interfaces that describes the artifacts that comprise the batch programming model to implement batch business logic, and a batch runtime for running batch jobs, according to a defined life cycle.
The batch runtime is a part of the Java EE 7 runtime and has full access to all other features of the platform, including transaction management, persistence, messaging, and more.
The Oracle WebLogic Server implements the Java EE specification and is the Java EE server vendor for BDI. The WebLogic server provides many additional services beyond the standard services required by the Java EE specification.
|
Note: Review the WebLogic Application Server documentation for more information:http://docs.oracle.com/middleware/12213/wls/index.html http://www.oracle.com/technetwork/middleware/fusion-middleware/documentation/index.html |
Batch processing for Java platform was introduced in Java EE 7. It provides a programming model for batch applications and a runtime to run and manage batch jobs.
Batch processing is the execution of a series of programs ("jobs") on a computer without manual intervention.
JSR 352 defines:
Implementation: A programming model for implementing the artifacts
Orchestration: A Job Specification Language, which orchestrates the execution of a batch artifact within a job
Execution: A runtime environment for executing batch application, according to a defined lifecycle
The diagram below is a simplified version of the batch reference architecture that has been used for decades. It provides an overview of the components that make up the domain language of batch processing.
The Job Operator provides an interface to manage all aspects of job processing, including operational commands, such as start, restart, and stop, as well as job repository related commands, such as retrieval of job and step executions.
The Job Repository holds information about jobs currently running and jobs that ran in the past.
A step contains all the necessary logic and data to perform the actual processing.
A chunk-style step contains ItemReader, ItemProcessor, and ItemWriter.
A job encapsulates the batch process. A job contains one or more steps. A job is put together using Job Specification language (JSL) that specifies the sequence in which steps must be executed.
A step is a domain object that encapsulates an independent, sequential phase of a batch job. Therefore, every Job is composed entirely of one or more steps. A step contains all of the information necessary to define and control the actual batch processing.
ItemReader is an abstraction that represents the retrieval of input for a step, one item at a time. When the ItemReader has exhausted the items it can provide, it will indicate this by returning null.
ItemWriter is an abstraction that represents the output of a step, one batch or chunk of items at a time. Generally, an item writer has no knowledge of the input it will receive next, only the item that was passed in its current invocation.
The remainder of this document describes the implementation of the BDI product using Java Batch and JavaEE.
