This chapter covers the following topics:
Java service beans are a key component in the Oracle E-Business Suite's cohesive architecture for developing, testing, cataloging and securing public and private interfaces. A single set of implementation instructions and guidelines are used to create service beans, which are automatically published to a centralized interface repository when the code is source controlled. The automatic technology-specific generators read from the interface repository service bean definitions to create Web service session beans.
When creating a Web service, the following files are used:
a WSDL document that describes the Web service's interface in XML,
the service endpoint interface (SEI) that defines the Web service interface in the Java language,
a service implementation bean, or service bean, that implements the Java service interface, and,
one or more deployment descriptors that associate the WSDL, the Java interface, and the service bean together.
Services are self-describing, standalone components that can be deployed as Web services, EJB session beans or as co-located Java APIs, i.e., the APIs are deployed in the same Java Virtual Machine [JVM] as any client that uses them.
Service interfaces are categorized based on their intended usage.
A business object is a representation of an object in the business domain. A business object service provides access to, and operations on, business objects. A business object service may support a single or many business objects. A business object service can be a document, a place, a person, or a thing. It contains one or more view objects (VOs) that are mapped to underlying entities (EOs). A major difference between the view object and the underlying entity object is the presence of foreign attributes on the view object, such as the supplier name on the purchase order.
Application services are components that include data and operations. An application service is optimized for a specific end user task whose user interface can be implemented in any technology.
Application services are analogous to a root UI application module in a traditional OA Framework application and they might both provide access to business objects and share the same underlying entity objects.
A major difference between business object services and application services is the kind of data objects and tasks they support. A business object service manages core transaction data designed to be accessed by a remote system. An application service is optimized for a specific task, or group or tasks and also includes display values for presentation to a user. The application service will also include supplemental data objects to be used for lists, list of values and other UI-specific components.
A web service is a standalone software program that can be run on the Internet. While a Web service can be very small (an application that lets you get the current time, for example), or large and complex, all Web services leverage the standard technologies that together enable dynamic discovery and interaction.
The Oracle Web service framework operates in a manner in which automated, decentralized services can be defined, deployed, manipulated and evolved. The framework provides a structure for integration and foundation for protocols that will support the needs of service-oriented applications. The Oracle Web services framework provides the control infrastructure within the middle-tier to authenticate, validate, serialize or de-serialize and ultimately invoke the service bean layer within the OA framework to process a client Web service call or request.
The new Web services are described by a Web Service Description Language (WSDL) file that you can discover, download and consume using Web service tools of your choice to invoke the new services. The document-style Web services are loosely coupled and document-driven. The client sends the parameter to the Web service as XML document, instead of discrete set of parameter values to the Web Service. The input XML document can also be described in the WSDL. The Web Service receives entire document, processes it and returns a response message. The protocol places no constraint on how the document needs to be structured, which is totally handled at the application level.
The Integration Repository, an integral part of Oracle E-Business Suite, is a central store of interface data for Oracle customers, partners, and internal departments. It also includes a catalog of services that the client may invoke to perform a business function or operation.
The iRep provides a complete catalog of Oracle E-Business Suite's business interfaces, and a comprehensive view of the interface mechanisms available. You can use this tool to easily discover and deploy the appropriate business interface from the catalog for integration with any system, application, or business partner.
Related Topics
Oracle Integration Repository User Guide
Implementing the Web service involves deploying the Web service on a server, assigning privileges to users who can access the Web service, and invoking the Web service from a Web service invocation client.
Use the following steps to deploy the Web service on a server. You must have the Integration Repository Administrator role to deploy a Web service.
Navigate to Integration Repository.
Select Interface Type from the View By list.
Select Web Service > Financials > Receivables.
Click each service.
Click Deploy Web Service.
Use the following steps to assign privileges to users.
Navigate to Integration Repository.
Select Interface Type from the View By list.
Select Web Service > Financials > Receivables.
Click each service.
Click Select All under Methods.
Click Create Grant.
Select the type of grant from the Grantee Type list.
Select the Grantee Name to add a user who will access the Web service.
Click Apply.
Enter the appropriate values for the parameters to invoke the Web service. The parameters can be specified using any Web service invocation client (such as BPEL and Apache-Axis).
You can also create invocation methods based on your requirements.
The following table lists the APIs you can access through the respective service beans :
| Service Bean | Object | Business Object | Equivalent API Procedure |
| Organization | CreateOrganization UpdateOrganization SaveOrganization GetOrganization getOrganizationsCreated getOrganizationsUpdated |
HZ_ORGANIZATION_BO_PUB | create_organization_bo update_organization_bo save_organization_bo get_organization_bo get_organizations_created_bo get_organizations_updated_bo |
| Organization Customer | CreateOrganizationCustomer UpdateOrganizationCustomer SaveOrganizationCustomer GetOrganizationCustomer GetOrganizatonCustomerCreated GetOrganizationCustomerUpdated |
HZ_ORG_CUST_BO_PUB | create_org_cust_bo update_org_cust_bo save_org_cust_bo get_org_cust_bo get_org_cust_created_bo get_org_cust_updated_bo |
| Person | CreatePerson UpdatePerson SavePerson GetPerson GetPersonCreated GetPersonUpdated |
HZ_PERSON_BO_PUB | create_person_bo update_person_bo save_person_bo get_person_bo get_person_created_bo get_person_updated_bo |
| Person Customer | CreatePersonCustomer UpdatePersonCustomer SavePersonCustomer GetPersonCustomer getPersonCustomerCreated getPersonCustomeerUpdated |
HZ_PERSON_CUST_BO_PUB | create_person_cust_bo update_person_cust_bo save_person_cust_bo get_person_cust_bo get_person_cust_created_bo get_person_cust_updated_bo |
| Party Site | CreatePartySite UpdatePartySite SavePartySite GetPartySite |
HZ_PARTY_SITE_BO_PUB | create_party_site_bo update_party_site_bo save_party_site_bo get_party_site_bo |
| Organization Contact | CreateOrgContact UpdateOrgContact SaveOrgContact GetOrgContact |
HZ_ORG_CONTACT_BO_PUB | create_org_contact_bo update_org_contact_bo save_org_contact_bo get_org_contact_bo |
| Phone | CreatePhone UpdatePhone SavePhone GetPhone |
HZ_CONTACT_POINT_BO_PUB | create_phone_bo update_phone_bo save_phone_bo get_phone_bo |
| CreateEmail UpdateEmail SaveEmail GetEmail |
HZ_CONTACT_POINT_BO_PUB | create_email_bo update_email_bo save_email_bo get_email_bo |
|
| Website | CreateWeb UpdateWeb SaveWeb GetWeb |
HZ_CONTACT_POINT_BO_PUB | create_web_bo update_web_bo save_web_bo get_web_bo |
| Location | CreateLocation UpdateLocation SaveLocation GetLocation |
HZ_LOCATION_BO_PUB | create_location_bo update_location_bo save_location_bo get_location_bo |
| Relationship | CreateRelationship UpdateRelationship SaveRelationship GetRelationship |
HZ_PARTY_BO_PVT | create_relationship_obj uodate_relationship_obj save_relationship_obj get_relationship_obj |
Oracle Trading Community Architecture Technical Implementation Guide
You can search for a list of parties of type Organizations, or Persons, that match a configurable set of search criteria defined in a DQM match rule within the Oracle Trading Community infrastructure using the SearchParty service bean. However, you cannot use the DQM search service to search for a party contact.
The following signature should be used to specify the input and output associated with the searchParty service:
Search Type
A match rule ID along with the attributes and values.
Match Rule ID
A technical identifier that uniquely identifies every match rule created within an Oracle Customer Data Hub (CDH) or Oracle Customer Data Librarian (CDL) instance.
Search Attributes
The attribute name and value pairs of all search parameters. A maximum of 20 search attributes can be specified at any given time to allow Oracle Data Quality Management (DQM) to successfully execute a search operation.
This data object captures the results of a search including a list of parties (party name), match score, registry IDs and the, related source system name and the original system reference IDs corresponding to search hits.
The following table lists the search result data objects that are created as part of the searchParty service bean:
| Column Description | Column Name | Data Type | Length |
| Party ID | PARTY_ID | Number | |
| Match Score | MATCH_SCORE | Number | |
| Registry ID | PARTY_NUMBER | VARCHAR2 | 30 |
| Party Name | PARTY_NAME | VARCHAR2 | 360 |
| Party Type | PARTY_TYPE | VARCHAR2 | 30 |
| Organization/Person Address1 (Primary) | ADDRESS1 | VARCHAR2 | 240 |
| Organization/Person Address2 (Primary) | ADDRESS2 | VARCHAR2 | 240 |
| Organization/Person Address3 (Primary) | ADDRESS3 | VARCHAR2 | 240 |
| Organization/Person Address4 (Primary) | ADDRESS4 | VARCHAR2 | 240 |
| Organization/Person City (Primary) | CITY | VARCHAR2 | 60 |
| Organization/Person State (Primary) | STATE | VARCHAR2 | 60 |
| Organization/Person Country (Primary) | COUNTRY | VARCHAR2 | 60 |
| Organization/Person Country Code (Primary) | PRIMARY_PHONE_COUNTRY_CODE | VARCHAR2 | 10 |
| Organization/Person Area Code (Primary) | PRIMARY_PHONE_AREA_CODE | VARCHAR2 | 10 |
| Organization/Person Phone Number (Primary) | PRIMARY_PHONE_NUMBER | VARCHAR2 | 40 |
| Organization/Person Email (Primary) | PRIMARY_EMAIL | VARCHAR2 | 2000 |
| Original System Object Reference | ORIG_SYS_OBJS | HZ_ORIG_SYS_REF_OBJ_TBL |
A spoke application can use this Web service to create a request to merge two or more parties. A spoke application can use this Web service to retrieve details about a party merge request. This Web service has two operations – Create Party Merge Request and Get Party Merge Details.
You can use this Web service to create a request to merge parties.
Input
Duplicate ID Object: The data object oracle.apps.ar.hz.service.party.DuplicateParty contains the list of potential duplicate IDs and/or a combination of the source system and the source system IDs provided by the user.
Initialized Message List: The list that indicates if the FND message stack within the API is initialized.
Note: The note for the merged text
Output
Merge Request ID: The output is the ID of the merge request that will be shown in the Create Party Merge Request Payload XML document.
You can use this Web service to retrieve details about a party merge that has already taken place in the Customer Data Hub.
Input
Batch ID: The party merge batch identifier.
Merge to Party ID:The master party identifier.
Get Merge Details Flag: The flag that indicates if the historical merge party details from the HZ_Merge_Party_History table and associated source system mapping details are retrieved as part of the object.
Initialized Message List:The list that indicates if FND message stack within the API is initialized. By default the FND message stack is not initialized.
Output
Party Merge Object: The output is the PL/SQL table of records structure that contains the party merge result information.
You can use this Web service to retrieve details about the account merge for a merge that has already taken place. This Web service has one operation - Get Account Merge Details.
Input
Customer Merge Header ID: The header ID displays the customer merge header numbers.
Initialized Message List: The list that indicates if FND message stack within the API is initialized. By default, the FND message stack is not initialized.
Get Merge Details Flag: The flag that indicates if the historical merge account details from history tables and associated source system mapping details are retrieved as part of the object.
Output
Account Merge Object V2: The output is the data object oracle.apps.ar.hz.service.account.AcctMergeObj. It returns the account merge information, which is shown in the Get Account Merge Details Payload XML document.