14.

2 Constructing an ABCS Using Service Constructor

AIA Service Constructor is an application that helps jump-start ABCS development by
pregenerating AIA artifacts complying with architectural recommendations. It generates
artifacts according to the AIA architecture naming recommendations and relieves developers
of performing repeatable mundane tasks, making them focus more on value-added business
scenario-specific tasks.
For more information about the Service Constructor, see Chapter 4, "Working with Service
Constructor."
This section includes the following topics:

Section 14.2.1, "How to Create the ABCS in the Service Constructor"

Section 14.2.2, "How to Complete ABCS Development for the AIA Service
Constructor"

14.2.1 How to Create the ABCS in the Service Constructor

See Chapter 4, "Working with Service Constructor."

14.2.2 How to Complete ABCS Development for the AIA Service Constructor
After the ABCS is created in the Service Constructor, the following post-ABCS construction
tasks must be performed manually.
Complete the following manual post-ABCS construction tasks:
Tip:
Ensure that the required AOL schemas are available in the MDS on the server.
1. Move abstract WSDLs of Application Business Service Connector to the MDS.
Refer to Section 2.1.3.4, "Using MDS in AIA."
2. Configure the JDeveloper to access the MDS repository.
Refer to Section 2.1.3.4, "Using MDS in AIA."
To complete ABCS development for the AIA Service Constructor:
1. Rearrange service invocations, if necessary.
The AIA Service Constructor generates relevant definitions for all external service
invocations in a sequence in the order that you specify while using the wizard. If your
ABCS requires that the invocations be done either in parallel or based on certain other
conditions, rearrange the services as needed using Oracle BPEL Designer.

2. Complete the business payload transformation.

The AIA Service Constructor generates transformations only if the target document is
an Enterprise Business Message and generates root element business transformations
only. It generates the transformation mapping pertaining to most of the header
elements, and the XSL code pertaining to the business payload that is common to all
of the ABCSs.
Use Oracle BPEL Designer to develop the transformation code for transforming
remaining parts of the message document to complete the business payload and
header transformation.
3. Configure correlation properties for asynchronous application service invocation.
The AIA Service Constructor does not generate correlation properties for any
application target service that is being invoked using an asynchronous requestresponse MEP.
Use Oracle BPEL Designer to configure the correlation upon the invoke activity and
subsequent receive activity.
4. Create invocations for other operations when a service is called multiple times.
If a service is called multiple times, the AIA Service Constructor does not generate
code for multiple invocations. Copy and paste the invocation code generated for the
first service invocation from the same process and rename operations and variables.
5. Populate attributes of binding.ws element of the reference services in the
composite.xml file.
Tip:
Always use the abstract WSDL to refer to the services that must be invoked. The
reference binding component should always use the abstract WSDL.
Do not use the concrete WSDLs directly in your consuming artifacts.
Do not reference the deployed concrete WSDL of a Service Provider
The following paragraphs describe how you can accomplish this.
For a better understanding of why this is recommended, see Section 27.1.6,
"Separation of Concerns."
In the composite.xml file, under the element <reference>, the AIA Service
Constructor generates empty attributes, port, and location for the element
<binding.ws>.
Populate the attributes with relevant values as specified in the following list.

1. When the referenced service is BPEL-based, the binding.ws element should be

populated as shown in Example 14-1.
Example 14-1 Binding.ws element for BPEL-based Service
<binding.ws port="[Namespace of the Service as defined in the
wsdl]#wsdl.endpoint([Name of the Service as given in the
WSDL]/[ Name of the
Porttype as given in the WSDL>)" location="< URL of the
concrete WSDL]"/>

Tip:
The name of the Service is the value of the attribute definitions/name in the
abstract WSDL.
This follows from naming conventions for the Service name in the ABCS
Composite. The name of the service is <name of the composite>, which in
turn is the value of the attribute 'name', of the element 'definitions', in the
WSDL.
The URL of the concrete WSDL uses this format as shown in Example 14-2:
Note:
Populating the 'location' attribute of the element binding.ws with the URL of a
run-time WSDL, does not amount to voilating the principle of 'designing the
service using only abstract WSDLs'. The reason is that this concrete WSDL is
not accessed either at composite's design-time or at composite's deploy-time.
This WSDL is only accessed at composite's run time.
http://{host}:{port}/soa-infra/services/default)/[Name of the Service as given
in the attribute 'name' of the element 'definition' in the WSDL]/[Name of the
Porttype element as given in the WSDL]?WSDL
Example 14-2 URL of the Concrete WSDL for BPEL-based Service
<binding.ws
port="http://xmlns.oracle.com/SamplePortalApp#wsdl.endpoint(Sam
plesCreateCustomer
PartyPortalProvider/SamplesCreateCustomerPartyPortalProvider)"
location="http://
{host}:{port}/soainfra/services/default/SamplesCreateCustomerPartyPortalProvider
/SamplesCreateCustomerPartyPortalProvider?WSDL"/>

2. When the referenced service is mediator-based, then the binding.ws element

should be populated as shown in Example 14-3.
Example 14-3 Binding.ws element for Mediator-based Service
<binding.ws port="[Namespace of the Service as defined in the

wsdl]#wsdl.endpoint([Name of the Porttype element as given in

the WSDL]_ep/[
Name of the Porttype element as given in the WSDL]_pt)"
location="[ URL of the
concrete WSDL]"/>

The URL of the concrete WSDL uses this format as shown in Example 14-4:
http://{host}:{port}/soa-infra/services/default)/[Name of the Porttype element
as given in the WSDL]/[Name of the Porttype element as given in the
WSDL]_ep?WSDL
Example 14-4 URL of the Concrete WSDL for Mediator-Based Service
<binding.ws
port="http://xmlns.oracle.com/EnterpriseServices/Core/CustomerP
arty/V2#wsdl.endpo
int(SamplesCustomerPartyEBS_ep/CustomerPartyEBS_pt)"
location="http://
{host}:{port}/soainfra/services/default/SamplesCustomerPartyEBS/SamplesCustomerP
artyEBS_ep?WSDL"/>

TroubleshootingTip:
You may see error messages indicating invalid SOA composites after a server
restart. This is caused by referring to concrete WSDLs where abstract WSDLs
should have been used.
You will not see the problem at the first deployment of a new composite X
when you reference the concrete WSDL of composite Y. Why? Composite Y
is up and running at the time of the deployment of composite X. The problem
starts when the server is restarted because there is no guarantee that the
composites will be activated in the right order to resolve any dependencies. If
service X is activated before composite Y, the reference cannot be resolved
because Y is still down, so X remains in status Invalid.
6. Alter policies in the fault policy.
The AIA Service Constructor generates fault policies with default values. Modify
these default values based on the service's requirements.
For details about setting up fault policies for AIA services, refer to Chapter 24,
"Configuring Oracle AIA Processes for Error Handling and Trace Logging."
7. Alter properties in the service configuration properties file.
The AIA Service Constructor generates a configuration file snippet for servicespecific properties. In case of the service configuration file of a provider ABCS, you
must enter the value for the property Routing. <PartnerLinkName>.< Target System
ID>>.EndpointURI as shown in Example 14-5.

Example 14-5 Service Configuration Properties File

<Property name="Routing. PartnerLinkName>.< Target System
ID>.EndpointURI
">http://[hostname]:[portnum]/soa-infra/services/default/[name of the
service]/[name of the exposed endpoint of the
service]?WSDL</Property>

Example 14-6 is a sample of a completed service configuration properties file.

Example 14-6 Example of Configuration File for Service-specific Properties
<Property
name="Routing.SamplesCreateCustomerPartyPortalProvider.SamplePortal.E
ndpointURI">
http://
{host}:{port}/soainfra/services/default/SamplesCreateCustomerPartyPortalProvider
/SamplesCreateCustomerPartyPortalProvider?WSDL</Property>

Note:
You must provide the preceding property in the service configuration file if the value
for the property Routing.<PartnerLink>.RouteToCAVS is given as false.
8. Change the componenttype file and composite.xml as detailed in the following
sections.
You must make changes to these files to make them point to the abstract WSDLs in
the MDS.
Changes Needed in the componenttype File
The attribute ui:wsdlLocation in Service element should point to abstract WSDLs in the MDS
as shown in Example 14-7.
Example 14-7 Componenttype File Pointing to Abstract WSDLs in the MDS
<service
ui:wsdlLocation="oramds:/apps/AIAMetaData/AIAComponents/ApplicationConnecto
rServ
iceLibrary/SampleSEBL/RequesterABCS/SamplesCreateCustomerSiebelReqABCSImpl.
wsdl"
name="SamplesCreateCustomerSiebelReqABCSImpl">

If the composite has a reference, then the attribute ui:wsdlLocation in reference element
should point to abstract WSDLs in the MDS as shown in Example 14-8:
Example 14-8 Componenttype File for a Composite with a Reference
<reference name="SamplesCreateCustomerPartyPortalProvider"
ui:wsdlLocation="oramds:/apps/AIAMetaData/AIAComponents/ApplicationConnecto
rServ
iceLibrary/SamplePortal/V1/SamplesCreateCustomerPartyPortalProvider.wsdl">

<interface.wsdl
interface="http://xmlns.oracle.com/SamplePortalApp#wsdl.interface(SamplesCr
eateC
ustomerPartyPortalProvider? )"/>
</reference>

Changes Needed in the composite.xml File

In the composite.xml, the attribute location of the element import should point to abstract
WSDLs in the MDS as shown in Example 14-9.
Example 14-9 Composite.xml Pointing to Abstract WSDLs in the MDS
<import
location="oramds:/apps/AIAMetaData/AIAComponents/ApplicationConnectorServic
eLibr
ary/SampleSEBL/RequesterABCS/SamplesCreateCustomerSiebelReqABCSImpl.wsdl"
namespace=
"http://xmlns.oracle.com/ABCSImpl/Siebel/Samples/CreateCustomerSiebelReqABC
SImpl
/V1"/>

The attribute ui:wsdlLocation in Service and Reference elements should point to abstract
WSDLs in the MDS as shown in Example 14-10.
Example 14-10 Example of composite.xml Pointing to Abstract WSDLs in the MDS
<service
ui:wsdlLocation="oramds:/apps/AIAMetaData/AIAComponents/AIAServiceLibrary/S
ample
SEBL/RequesterABCS/SamplesCreateCustomerSiebelReqABCSImpl.wsdl"
name="SamplesCreateCustomerSiebelReqABCSImpl">

For those referenced services in which the WSDLs do not have partnerLinkType elements in
them, their corresponding reference WSDLs should also be changed to refer the abstract
WSDLs from the MDS.
For instance, the composite of a requester ABCS has a mediator as a referenced service.
Hence, change the location attribute of the element 'import' in the <EBS Reference WSDL>
file as shown in Example 14-11.
Example 14-11 Referenced Service WSDLs with no partnerLinkType Elements Pointing to
Abstract WSDLs in the MDS
<wsdl:import
namespace="http://xmlns.oracle.com/EnterpriseServices/Core/CustomerParty/V2
"
location="oramds:/apps/AIAMetaData/AIAComponents/EnterpriseBusinessServiceL
ibr
ary/Core/EBO/CustomerParty/V2/CustomerPartyEBS.wsdl"/>