BPEL Process Features

BPEL Process Features
With BPEL, you can define business processes that make use of services, and business processes that expose their functionality as services. When defining an executable business process in BPEL, you actually define a new service that is a composition of existing services.

• You can define both simple and complex business processes with BPEL. BPEL provides constructs such as loops, branches, variables, assignments, and so on, which allow you to define business processes in an algorithmic manner. The most important BPEL constructs are related to the invocation of services.
• With BPEL, you can invoke operations of services either synchronously or asynchronously, and manage callbacks that occur later.
• BPEL supports long-running process and compensation, which allows undoing partially failed work done by a process.
• You can schedule activities based on the execution time and define their order of execution.
• You can also invoke operations either in sequence or in parallel.
• BPEL provides fault handling, which is very important, because robust business processes need to react to failures in a smart way. BPEL can also capture events published external to the BPEL process instance and process them in a meaningful way.

You can also read: What is BPEL?

What Is BPEL?

What Is BPEL?

Business Process Execution Language (BPEL) is:

A markup language for orchestrating services into an end-to-end process flow

BPEL is a specialized language focused on the definition of business processes. BPEL Process components are instances of BPEL implementations that execute in the BPEL Process Manager service engine.

A BPEL Process receives messages and orchestrates, through different invocation patterns, one or more services that contribute to completing a business process flow.

Built on top of XML-related specifications

BPEL uses an XML-based vocabulary to describe business processes, and is based on WSDL, XSD, and XPath specifications.

Executed by a BPEL engine that can process the BPEL XML source

Oracle SOA Suite 12c provides a runtime environment for executing composite applications developed in BPEL.

You can also read BPEL Process Features

SOA, Web Services, and REST

SOA is an architectural approach to composition and integration.

SOAP-based web services is the most common way to implement SOA. They:
Address the low-level interactions between services
Help up to a certain level of complexity in the infrastructure

REST architecture provides an alternative medium by which SOA can be implemented.
REST tries to establish application architecture that emulates the World Wide Web.

SOAP and REST

Web services are of two kinds:

•                  Simple Object Access Protocol (SOAP) and 
•                   Representational State Transfer (REST).

SOAP-Based Web Services

SOAP-based web services is an important technology used to implement many services, but there are alternative service implementation technologies, such as REST. Web services are based on a core set of communication standards:
SOAP (to communicate) defines an XML-based structure for passing information, such as messages and data, between web services and applications.
WSDL (to describe) is an XML-based language for modeling web services. A WSDL document describes the service interface, message format, and the service instance location.
UDDI (to advertise and syndicate) allows organizations to register their web services in a uniform manner within a directory, so clients can locate their web services and learn how to access them.
The benefit of using web services artifacts such as WSDL and XSD is that they are “accepted standards.” These XML document structures are easily exchanged using the standard Internet (web services) protocols such as Hypertext Transfer Protocol (HTTP) among others.
SOAP, WSDL, and UDDI are standards at the core of web services, and they are followed by many additional specifications that define reliability, security, metadata management, transactions to meet requirements for enterprise features, and qualities of service. These specifications are collectively referred to as the WS-*.
Note that using a service-oriented design approach does not require SOAP web services; however, web services is the most common way to implement SOA. 

Representational State Transfer (REST) Web Services

REST-based services are based on a very different model than SOAP-based services. The model is based on resources. The idea is that you send a request for a resource, the resource that is returned shows you the options for the next step. This model is very flexible and does not require that the client know in advance what services and service calls are available.
REST services rely on a stateless, client-server, cacheable communications protocol—and in virtually all cases, the HTTP protocol. HTTP methods such as GET, PUT, POST, and DELETE are used to represent CRUD type operations (Create, Read, Update, Delete).
RESTful services do not impose constraints on the data format exchanged. Data can be formatted as XML, HTML, JavaScript Object Notation (JSON), and so on.

Introduction to AIA PIP

What is AIA
Application Integration Architecture is an open, standards-based platform that is designed to ease integration of disparate applications into a unified enterprise architecture using service-oriented architecture (SOA). AIA provides an integration framework for enabling cross-application business processes, which spares organizations the effort of having to customize their applications to achieve the same end within a single, common application suite, such as Oracle E-Business Suite or Oracle Siebel applications. It can be used to link together Oracle applications, custom applications or any combination of enterprise legacy applications.

AIA Components

AIA consists of three components:

1. The Foundation Pack, 
2. Process Integration Packs and
3. Direct Integrations.

All of which use Oracle Fusion Middleware as the technology platform. The Foundation Pack sits on top of the Oracle SOA Suite to provide the common framework and object models; the Process Integration Packs are built on top of the Foundation Pack to facilitate composite business process integrations of two or more Oracle applications. Direct Integrations are a prebuilt tightly coupled data integration solution between two applications

Starting lot number prefix is required when Lot Control = Full lot control

While releasing a part from Agile getting below error.

Error: Starting lot number prefix is required when Lot Control = Full lot control

Cause You have to specify Lot Prefix in the  template when you have Lot Control=Full Lot Control.

Resolution Please correct the Item Templates in Oracle EBS and resubmit the ECO from AIA queue.

Err Msg INV INV_INVALID_ARG_NULL_VALUE

Error INV INV_INVALID_ARG_NULL_VALUE 

When an ECO being released from Agile PLM, getting below error in AIA PIP

Org Code MST ECO Name ECO00018 Err Msg INV INV_INVALID_ARG_NULL_VALUE


This could be because, category set which is being sent from Agile is not valid Oracle EBS.
You need check, if the category set is valid in Oracle EBS or not.

Use below code for the same,


SELECT    (segment1)|| '.'
       || (segment2)|| '.'
       || (segment3)|| '.'
       || (segment4)|| '.'
       || (segment5)|| '.'
       || (segment6)|| '.'
       || (segment7) cat_set,
       mc.segment1,
       mc.segment2,
       mc.segment3,
       mc.segment4,
       mc.segment5,
       mc.segment6,
       mc.segment7
  FROM mtl_categories_b mc
 WHERE     enabled_flag = 'Y'
       AND NVL (end_date_active, SYSDATE) >= SYSDATE
       AND    (segment1)
           || '.'|| (segment2)
           || '.'|| (segment3)
           || '.'|| (segment4)
           || '.'|| (segment5)
           || '.'|| (segment6)
           || '.'|| (segment7) LIKE     '&p_cat_set';


Make sure you have the category defined in Oracle and try to resubmit the ECO from AIA queue.

SCA vs SOA

Service Component Architecture VS Service Oriented Architecture

It's a set of specifications that defines an assembly model for composite services and also provides a programming model to build applications which are SOA-based.

A composite service can have several business processes, bindings, properties, human workflows, etc. all put together. We define a Composite and once the Composite is ready it's for you to be treated as a single component and can easily be exposed as a composite service the way you expose a web service.

SCA makes the deployment design very easy. Suppose your application have n business processes and let's say BP-1 is the entry point to the application then you can define a composite by specifying the navigation details among the various business processes and/or human workflows and then you can expose BP-1 as a composite service. Now, the composite service is having a well-defined assembly of all the components involved in your application and ready to be deployed. You don't need to deploy the individual components separately. All will be handled by SCA. All the assembly information is stored in an SCA Descriptor.




SCA vs SOA 
SCA focuses on the assembly of various components to provide an easier design and deployment while SOA provides an architecture or style to design and develop the individual components. SCA comes into pictures only when you're ready with all the components. So, you create components with SOA and assemble them using SCA mainly to make the deployment easier.

SOA is an architectural style or approach.

SCA is an assembly model for SOA-style applications.

SOA

SOA is all about BPEL and Mediator

·         WSDL - Web Services Description Language

·         A sample WSDL document

·         Ways of combining Web Services. Orchestration vs Choreography

·         What all Request Response Patterns do we have in SOA?

·         Service Component Architecture (SCA). SCA vs SOA

·         Web Services - What, Why, How, and Shortcomings







SCA:

• An assembly model described by a set of specifications that define how to compose applications from components
• A definition of a design and deployment model for composite services

You can also read http://www.erptimes.com/2013/10/service-component-architecture-sca-and.html

Service-component architecture (SCA) and Overview of SOA

Service-component architecture (SCA) and Overview of SOA

Service-component architecture (SCA) is a group of specifications intended for the development of applications based on SOA, which defines how business process entities interact to perform business tasks.

•      SCA provides an open, technology platform independent model for implementing IT web services that are defined in terms of a business functions and make middleware functions more accessible to the application developer
•      SCA provides the Power of the Composite, a framework for standardizing and simplifying the building, deployment and management of atomic service components into a more granular composite.

SCA can be broken down into four major parts or models:

•      Assembly Model: defines how components are combined, linked and packaged as services independent of the programming language.
•      Implementation Model: defines how services are packaged and accessed for specific programming languages.
•      Policy Model: defines service policies independent of the programming code.
•      Binding Model: defines how components are accessed independent of the programming code.

Unable to create an instance of the Java Virtual Machine error

At times we get an error message “Unable to create an instance of the Java Virtual Machine” while opening JDeveloper.

OR

"Error occurred during initialization of VM

Could not reserve enough space for object heap"

 We can resolve this problem by increasing the virtual memory space for Jdeveloper. Follow below steps:
(This error was seen most of the times in 32 bit OS)

1. Find for file jdev.conf which is usually in the path <Jded_Root_Folder>/ jdevbinjdevbin
2. Search for a line with text “AddVMOption” and add this text “AddVMOption       -Xmx256M” below that line

After the change