Issue: Error code: SBL-EAI-04313 while invoking a Sibel Web Service from BPEL.

Error Details:

“There is no active Web Service with operation named 'http://siebel.com/asi/:SiebelAccountInsert'.(SBL-EAI-04313”

<detail>
   <siebelf:siebdetail xmlns:siebelf="http://www.siebel.com/ws/fault" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
      <siebelf:logfilename xmlns:siebelf="http://www.siebel.com/ws/fault" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">EAIObjMgr_enu_0024_25165939.log</siebelf:logfilename>
      <siebelf:errorstack xmlns:siebelf="http://www.siebel.com/ws/fault" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
         <siebelf:error xmlns:siebelf="http://www.siebel.com/ws/fault" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
            <siebelf:errorcode xmlns:siebelf="http://www.siebel.com/ws/fault" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">SBL-EAI-04313</siebelf:errorcode>
            <siebelf:errorsymbol xmlns:siebelf="http://www.siebel.com/ws/fault" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">IDS_EAI_WS_OP_NOT_FOUND</siebelf:errorsymbol>
            <siebelf:errormsg xmlns:siebelf="http://www.siebel.com/ws/fault" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">There is no active Web Service with operation named 'http://siebel.com/asi/:SiebelAccountInsert'.(SBL-EAI-04313)</siebelf:errormsg>
         </siebelf:error>
      </siebelf:errorstack>
   </siebelf:siebdetail>
</detail>

Solution:

I was able to resolve this issue by doing the the following:

1. Login to Siebel

2. Browse to Administration - Web Services

3. Within Siebel WS Administration, make sure that the status of WS is ‘Active’

4. Make sure that the Binding is set to SOAP_DOC_LITERAL

5. and finally Clear the Cache by clicking the “Clear Cache” button

 

To make the business service within E-Business Suite participate in your service oriented integration architecture as a web services. The integration approach used depends upon the requirements and the integration mechanism that is best suited to satisfy the requirements. To use one of the integration function in a SOA based solution (integration or composite process) is relatively simple with the help of Oracle Applications adapter by exposing them as web services. This enhances re-usability, extensibility, and faster design to deploy time frame.

Using EBS adapter has tremendous advantages. It exposes existing EBS Integration Interfaces as Web Services. The adapter inherently uses and leverages open standards, including J2CA, XML, WSIF, WSIL, and WSDL. Most importantly it dramatically reduces the time to design and develop a SOA based integration that interfaces with web service based integration interface for EBS.

To plan your soa based integrations, the architects and business users need to know what services are available within ebs that can be leveraged to be a part of your information integration, business process integration or coming up with composite application spanning across enterprise silos.

The first step when planning and designing your integrations should be to use Oracle Irep. This will give you the details of the business services available within EBS and also the details of service end-points. IRep lets users easily discover the appropriate business service interface for integration with any system, application, or business partner.

It is a pre-built central catalog of information about the numerous public integration interfaces delivered with Oracle applications, known as business interfaces.

The key advantages of using Irep are

Helps in better integration planning by providing information to make informed decisions

Acts as single source of truth for the available business servicesEnhanced re-use of existing components

Assurance that you are using supported public interfaces

Using Irep

Go to http://irep.oracle.com/

If you are working on EBS R12: From the Navigator menu, select the Integration Repository responsibility, then click the Integration Repository link that appears.

Browse IRep

: You can browse Irep using the categories of product or by the integration standards you wish to leverage.

Search IRep:

IRep also lets you search using various search parameters. You can search by interface name, internal name, product family, interface type (concurrent program, web service, XML gateway map etc), product, and business entities.

In Release 12, the Oracle Integration Repository will ship as part of the E-Business Suite. As your instance is patched, the repository will automatically be updated with content appropriate for the precise revisions of interfaces in your environment. But until Release 12 is available, you can explore an on-line version of the Integration Repository for the 11i10 version of E-Business applications.

It is important to understand different integration components available within EBS to make informed decision about using one or more for your SOA integration project. Selecting one or more of them depends upon the requirements and the interaction pattern determined to be best fit for the service oriented architecture based integration.
Following are the integration mechanisms available within e-Business suite.

Oracle XML Gateway:

E-Business Suite utilizes the Oracle Workflow Business Event System to support event-based XML message creation and consumption. It can consume events raised by the Oracle E-Business Suite and can subscribes to inbound events for processing. It can be leveraged for Business-to-Business (B2B) and Application-to-Application (A2A) integration scenarios. Majority of messages delivered with the Oracle E-Business Suite are mapped using the Open Application Group (OAG) standard.

Business Events:

The Oracle Workflow Business Event System is an application service that leverages the Oracle Advanced Queuing (AQ) infrastructure to communicate business events between systems. There are more than 1000 built in events with in EBS that can be leveraged for event-based integration of business processes.

Concurrent Programs:

A concurrent program is an instance of an execution file. Concurrent programs use a concurrent program executable to locate the correct execution file. Several concurrent programs may use the same execution file to perform their specific tasks, each having different parameter defaults.

Interface Tables:

Interface tables are intermediate tables into which the data is inserted first. Once the data gets inserted into the interface tables, the data is validated, and then transferred to the base tables. Base tables are real application tables that reside in the application database. The data that resides in the interface tables is transferred to the base tables using concurrent programs. Interface views provide a way to retrieve data from Oracle Applications. By using views, you can get synchronous data access to Oracle Applications.

PL/SQL APIs:

These are stored procedures that enable you to insert and update data in Oracle Applications.
Oracle e-Commerce (EDI) Gateway: Oracle e-Commerce Gateway provides a common, standards-based approach for Electronic Data Interchange (EDI) integration between Oracle Applications and third party applications. It is the EDI integration enabler for Oracle Applications.

Business Requirements: Seamless Information

Today businesses are changing faster than ever. Business models are evolving and being transformed every day. There are greater expectations in terms of innovation, business performance, results, and effective use of resources. All this is putting greater pressure on the organizations to find new ways to streamline their processes and share information effectively and seamlessly. In other words businesses today need to be more flexible and responsive than ever before to their customers, suppliers, partners, vendors, and most importantly changing business models.
As ERP systems are at the center of enterprise business model, they need to provide a way for the business processes to participate and collaborate with external applications, partners, and information. Enterprise applications are moving from being monolithic and self-contained to the being more and more flexible and collaborative.

Whats Wrong with Traditional EAI?

Traditional integration focused on solving some of the above-mentioned requirements by enabling data flow between silos and external applications. It helped to a certain extent but over the time the complexity and of the integrations started posing serious concerns. The issues were proprietary technology used for integrating applications was a gridlock and it was not easy to easily orchestrate business processes between the disparate applications using the traditional eai.
What is Service Oriented Architecture?
SOA as it relates to software paradigm is an agile architecture approach that is based on service-oriented principles of composition, abstraction, loose coupling, discoverability, and amalgamation. SOA inherently empowers scalability, evolution of services, interoperability, re-usability, and modularity.

Do we need SOA based Integrations?

Using SOA principles while designing application integrations results in SOA based application integration. Simplicity is desired for the traditional and complex world of integrations. Better and common sense approaches such as Service interactions and amalgamation supported by Open Standards should be enabled. SOA is needed for the following main reasons:

To provide seamless agility to business

To improve business process visibility

To simplify the current rigid and complex state of IT

To enhance efficiency and provide cost-effectiveness

To enable re-usability factor

To provide better quality of service

But you are still doing integration?

Yes. Besides the obvious advantages enumerated by everyone, the key advantage of this approach is that you are contributing to the future of the SOA of your enterprise. The integrations with service-oriented approach are loosely coupled with the infrastructure components and more flexible and refactorable. Logical end-points for integration services provide far more decoupling and is implementation agnostic. The components and integration services can be used for creating a composite application or business process later. The benefits of adopting SOA grow with time. Once you have these reusable components from across applications, application modules, and other enterprise software components, creating a new application is relatively easy and that�s when the full potential of SOA is realized.

Design your SOA Integrations

Most of the design depends on the requirements. But before applying the very same approach you took for your earlier integration project, you need to keep in mind is that the goal here is to come up with integration components that are designed for interoperability, re-usability, and modularity. The key to designing your SOA integrations is remembering that they are SOA based. Using and adopting SOA principles is the key. Always try to apply SOA principles composition, abstraction, loose coupling, discoverability, and amalgamation to your services and integrations.

Architecture Perspective: Guidelines for SOA based Integrations

Based on my experience, considering the following guidelines can help you realize the SOA vision for integrations with EBS. Most of the following guidelines are generic and can and have been applied to other ERP integrations as well.
Use standards: Using standards based technologies for your service-oriented integrations will help eliminate lock-down with products and companies. This is one of the biggest challenges with traditional EAI. This will enhance easy evolution, enhancement, and composition of business processes that may use services related to integrations.

Classify Integration Requirements:

Categorize requirements into data integration and business process integration. Identify message exchange patterns and use ESB functions (transportation, mediation, and routing) to model data integration processes. Use BPEL for modeling your processes that involve anything more than what can be satisfied with ESB functions. Many times it is hard to classify and try to fit a particular integration process in one of the two buckets. In such cases it will be a good idea to use layered approach and use ESB functions for data integration and use BPEL for future extensions to the business integration process.

Introduce Extensibility:

To deliver on the high hopes for soa based integration architecture solution, it is very important to do some forward thinking for the desired flexibility and agility in your integration architecture. To deliver on that, think hard early on ways to introduce extensibility and forward compatibility into the architecture and all the components including individual integrations and messages.

Service Enable Enterprise Application Functions:

Enterprise applications have many business functions and technology components that are application specific and depend on proprietary technologies. These components or functions should be service enabled before they can participate in the service oriented integration architecture. Using resource adapters is a way of connecting and interacting with the application specific components. It is important that the resource adapter is implemented using industry standards such as J2CA, WSIF, and WSDL and can provide a web service interface to the application specific functions.

Inject Resiliency:

Build resiliency into the individual integration processes. This may be easy to miss as even with the best architecture in place. Always think about all the �what if� scenarios and try to inject process level resiliency into the individual integration processes.

Exception Handling:

Despite all the forward thinking there are things that might and will go wrong. Define reusable, extensible, and agile approach to handle exceptions at process level and other unknown exceptions. Using a common exception handler service with extensible interface can provide the flexibility, re-usability, and extensibility.

Simplify Support Functions:

Any one who has worked with application integration can relate to the great deal of time and energy waste involved when troubleshooting integration issues. With asynchronous messaging and multiple services, the idea should be to ease the pains of traditional EAI support functions. This can be done by thinking ahead about how can support functions be empowered with better ways to provide information visibility and take actions. Notifications and human work-flow are some of the ways to empower your support team.

Human interaction and intervention:

Business processes inevitably will involve human interaction in some or other form. If your integration process involves such role based people interaction, plan ahead and use standards based mechanisms to have human work-flows.

Separate Business Rules:

The integration process probably is not a good place to embed and hard codes the business rules. Identify the rules and provide loosely coupling between your process and rules. This would provide the flexibility to change business rules dynamically without modifying or redeploying your integration services or processes.

Business Process Visibility:

Plan for providing visibility into your so integration or business process. This is very important because today enterprises have heterogeneous systems and applications and with integrations spanning multiple systems, it becomes very hard to have visibility in run time. Users (IT and Business) should be able to monitor and have visibility into your business processes and integrations.

Service Composition:

Provide the capability to provide business functionality that is composed of disparate and/or independent services. The composite solution may cater to an integration solution or a new future business process. Service composite architecture is the relevant standard that addresses service composition. It provides the specifications to describe the model for building applications and systems using a Service-Oriented Architecture (SOA).

SOA Governance:

In simple terms, plan for the capability to manage and apply policies for the services within the service portfolio of your integration services. This is critical for SOA and needs to be planned well to ensure better management and control of services.

Conclusion

Service oriented approach to enterprise integrations offers tremendous advantages over traditional EAI. Enterprise integrations can be converted into reusable and implementation agnostic useful services by applying very basic principles of flexibility, agility, and extensibility in all the components of service oriented integration architecture.

Get started with the new technology preview release of SOA Suite 11g!

Refer to this link for details:

Oracle SOA Suite 11 g - Technology Preview

I did not realize that its been a while since I posted anything on my blog. Well we all get busy once in a while and that was the case with me as I got really busy with my current project. The good thing is I have few things to share that came out of my experience working with BPEL.

For exception handling, I learned that the function called ora:getFaultAsString was missing from the bpel designer (10.1.3) and it was not returning the detailed information about the fault. There are two patches that can help on this issue 5672007 & 5841736.

The Falcon Has Returned

This is a very interesting story about the endangered Falcon (Peregrine) that returned to Oracle for nesting.

Read more here:
Falcon Story at UC Santa Cruz

And the best part is the live webcam of Saddie and her four newborn chicks at Oracle HQ
Check it out here!

Business Agility @ Service Oriented Architecture

We live in a constantly changing world. Technology and businesses are changing, emerging, and improving at a faster pace than ever
before. Business want the power to deliver products and services better and more
efficiently, to be able to excel, capture new opportunities, and
sustain competition. Technology innovation and improvements are striving to deliver on these requirements. From a business perspective, dynamics of such fast-changing world in terms of
technology can be daunting in terms of time to market cost, maintenance, training, and support. Replacing or re-writing entire systems
every time for new and improved functionalities is definitely a major concern.

Is IT just an unavoidable cost?

Arguments about IT being a cost are not rare in business
world. There is no doubt in my mind that innovations in IT systems have
propelled business abilities and enriched business processes in past years.
Definitely, there is high business value gained from IT systems. At the same
time organizations also have to deal with the "cost" components that
come with IT systems such as maintenance, support, enhancements, training etc.

The argument from my perspective, should not be about the
classification of cost components, but how all the components and their
interactions can be simplified to provide more value to the business.

I think simplicity can help!

Simplicity is highly desired in increasingly complex world
on IT. Direct incentives of infusing simplicity in IT architecture are
tremendous and do not require elaboration.

Direct derivative of simplicity in IT architecture approach
is Business Agility.

Simply put, "Simple is Powerful"

SOA translates to business agility. SOA is simple but very powerful architecture approach
for complicated systems and problems of IT world.

As I mentioned in my earlier post based on my experience,
SOA as it relates to software paradigm is an agile architecture approach that
is based on service-oriented principles of composition, abstraction, loose
coupling, discoverability, and amalgamation. SOA inherently empowers
scalability, evolution of services, interoperability, reusability, and
modularity.

Following diagram identifies high level concepts infused into SOA that help enhance business agility for an enterprise.

Inherent Interoperability

SOA empowers Inherent Interoperability between systems, business processes, and people (organizations).

Re-usability

Reusability factor in case of SOA is multi-fold because of standard based interfaces. Reusability is not new in software; what�s new is reusability across diverse systems, platform, and technologies. SOA components can be reused not only by the inherent system or technology but also by any system or process.

Modularity and Composition

SOA encourages Modularity that enhances the concept of Composition. Composite applications can be build based on changing business requirements and rolled out faster with less cost.

SOA Delivers

SOA enables faster development turn-around time,
faster realization of new inter and intra enterprise business processes, and
cost effective maintenance and upgrades.

All this translates to enhanced Business Agility. And I would like to call it.....

Business Agility @ SOA

As I
mentioned in the earlier post, following are the questions that I frequently encounter and was trying to find common sense answers for

• I have heard about it so much,
  but what exactly is SOA?
• What is a Service?
• What exactly do you mean when
  you say Service Oriented?
• What do you mean by Composite
  Services?
• What do you mean by Service
  Orchestration?
• What is different about
  Service Oriented approach for Enterprise Integration?
• How is one company's SOA
  different than the other?

So as I
thought while posting my first blog entry I did take a step back and revisited
the concepts from a common sense perspective to share my understanding. Here it is my experiment and thoughts shared...

Service
Oriented Architecture: The Beginning

What is a Service?

Service
means the performance of any duties or work for another. Service is provided by
a service provider and consumed by the service consumer. Simple!

Think
about it. We all use and provide services almost everyday in our day today
life.  Following are some examples of well-known services:

Service Provider: Government
Services Provided: Education Services,
Infrastructure Services, Police and Fire Services, Postal Services, and other
regulatory services

Service Provider: Financial Companies
Services Provided: Accounting Services,
Banking Services, Tax Services, and auditing services

Service Provider: Utility Companies
Services Provided: Electricity Services, Gas
Services, Communication Services, Water Services, and Waste Management services


Service Provider: Individuals
Services Provided: Employee Services (various
roles), Medical Services, Law and Attorney Services

One of
the formal definition of services in a business sense is �Service is any act
or performance that one party can offer to another that is essentially in
tangible and does not result in the ownership of anything.�

What is service oriented?

Any
approach simple or composite based on services and/or service-mix is service
oriented. So is it anything new? No, Actually we already live in a service
oriented world and Service oriented approach is so very common in our
surroundings. It exists universally and is the most fundamental functional
aspect of human life in our society. Service providers and consumers range from
an individual person to giant multinational corporations. Most companies
provide services that are outcome of services provided to them by individual
employees and may be other companies. Service oriented societies and cultures
demonstrate some common characteristics such as standard currencies,
governance, service composition, and service orchestration.

Before
we talk about Service Oriented approach for software architecture, let�s see
how some of the principles apply in real life example. Let�s go through my
example:

My Example of Service: Flight
Service

I
live in Denver and fly for work to customer locations frequently, the obvious
real life example I was able to think of was of an airline and the service
(flight) it provides. Let�s take an example of a service I have used often,
flight between Denver and San Francisco.

Thinking
from service perspective, the airline I use is the Service Provider of the
flight between Denver and San Francisco. Since I choose to pay for the flight
and use the service, which makes me the service consumer.

In
this example some of the things to note as they relate to SOA are the
following:

Service Abstraction

The
airline uses multiple services, goods, and equipments to provide this service
to the customers. The service in itself is very complex technically and is
composed of several other services. But from my perspective there is a well defined
but simple interface to consume this service. All I need to care about is
making the payment for ticket and be on time at the correct Airport and gate :)

I
don�t have to worry about paying the Airport for the services such as security,
gate fees, air traffic control, and the airline in-flight services. I also
don�t worry about how the airline manages their employees, equipment, goods,
and other services that they consume to provide me with this service.

This
demonstrates the concept of abstraction. Services abstract the logic and
implementation.

Service Loose Coupling

Abstraction
promotes loose coupling of services. As services are modular, logic contained
in them is independent of each other. Awareness of the service is enough for
the services to interact and thus they are loosely coupled. They can change
within their own boundaries without causing any change required to the
consumer.

In
my example, most of the individual services are loosely coupled and communicate
using standard interfaces. The airline relies on the services provided by
Airport for security and ATC, it does not actually know or have to interact
with specific persons providing these services. Airport can very well replace
the security and ATC personals and still provide the same service without any
awareness required on the service consumers side. Loose coupling is one of the
most important concepts of SOA.

Service Contract

Service
should be defined and be agreed upon by the provider and consumer. My airline
in this example agrees to provide me a seat in economy class, provide me with
the standard in-flight service, and fly me from Denver airport�s particular
gate to the SFO airport. I agree to this service by buying the ticket using
standard currency (USD in this case). I also agree to be physically present at
the airport at the defined time, look up for the gate information, go through
the security and walk to the defined gate. Besides the basic known things,
there is a formal contract between me and airline (service provider and the
consumer). Some of the standards components of service definition in our
example are Airports, Flight Numbers, Currency, and Security.

Service Discovery

The
airline that provide me this service is listed on my corporate travel web site
as well as other standard and known interfaces and thus can be discovered by me
or any other customer. The service should be discoverable.

Service Composition

The
airline service is composed of several other services internally. To provide
the service (flying between Denver and San Francisco) to me and other
customers, the airline uses various services from multiple service providers.
Following are the main category of services that are used by our airline to
provide the flying service

• Airport Services
• Employee Services
• Food Catering Services
• Entertainment Services
  

Following diagram represents the Service that is composed of several other
services. Thus the end service that I use is a composite service.

Like the diagram depicts, one service can be composed of multiple service components internally. There is a layer of abstraction and thus the consumer of the service does not need to know the details. SOA is based on the principle of Service Composition.

Service Orchestration

In a music world, the person orchestrating a music orchestra symphony decides what music
instrument is to be played and when it plays what is the note that it should
play. In our example, the flight service has to be perfectly orchestrated to
provide the desired level of customer satisfaction. Our
airline has to use internal and external services in an ordered and defined way
as a process flow. Every service component like drinks, video, audio, announcements are well planned and orchestrated. The airline decides the process flow, execution, and timing of
services that we noticed in the diagram above for service composition. Every
process in the service has to be executed in a perfect order and style.

This is Service Orchestration and is a very important component of SOA.

Important Characteristics of
Service Orientation

Based on my understanding I came up with the following main characteristics or Service Orientation

• Service
  Discoverability
• Service
  Interactions and Amalgamation supported by Open Standards
• Service
  Composition
• Service
  Abstraction
  
• Service
  Loose Coupling
• And
  also importantly Service Real World Effects

What is Service Oriented
Architecture?

If
we are already living in a world that works based on service oriented approach,
what is so different about applying it to software architecture? What is the
entire buzz about?

SOA
is a simple and common sense approach adopted from the way things work in our
surroundings to the more complex, tightly coupled, and rigid world of software.

SOA
as it relates to software paradigm is an agile architecture approach that is
based on service-oriented principles of composition, abstraction, loose
coupling, discoverability, and amalgamation. SOA inherently empowers
scalability, evolution of services, interoperability, reusability, and
modularity.

Why is SOA Needed?

Simplicity
is desired for the traditional and complex IT world. Better and common sense
approaches should be enabled. SOA is needed for the following main reasons:

• To provide seamless agility to business
  
• To improve business process visibility
  
• To simplify the current rigid and complex state of IT
• To enhance efficiency and provide cost-effectiveness
• To enable reusability factor
• To provide better quality of service

How is one company's SOA
different than the other?

SOA as such is not a product that
can be bought, rather is an approach towards building modular software using
service-oriented principles. There are tools that can be used to realize the
service-oriented approach efficiently. Many companies provide tools for
assisting enterprise software implementation based on services and
service-oriented architecture approach. In case of Oracle, the components for SOA are bundled as SOA Suite which is a complete set of service infrastructure components for building, deploying, and managing SOAs.

Find more about Oracle SOA Suite