6 Working with JD Edwards EnterpriseOne as a Web Service Provider

This chapter contains the following topics:

6.1 Understanding JD Edwards EnterpriseOne as a Web Service Provider

You use JDeveloper and the Business Services Framework to create published business services and business services.

Note:

Do not use JDK 1.6-specific APIs in any of the published business services code if you want to be able to build business services packages for OAS, WAS, and WebLogic.

6.1.1 Published Business Services

A published business service is an Object Management Workbench (OMW) object consisting of one or more classes. One of the classes is the published business service class, which is the class that publishes methods that are exposed to the public. This public method wraps an internal business service method, where the actual business logic is performed. The published business service contains the value object classes that are received and returned by the published methods. A web service is generated from the published business service class, and the public methods of this class are operations within that web service.

After a business service is published, you cannot change the name and signature of the business service without affecting the consumers of that service. If you change an underlying business service that the published method exposes, then you change the signature and contract of the published business service.

6.1.2 Business Services

A business service is an OMW object consisting of one or more classes. One of the classes is a business service class, which is a Java class that has public methods that are used by other business services and published business services. The methods access logic in JD Edwards EnterpriseOne and support a specific step in a business process. When you create the business service class, you should consider including methods that have similar functionality and manageability in the same business service class. If multiple processes are similar and can reuse code, then these methods should exist in the same business service.

You can modify a business service providing that the change does not alter the signature or behavior of the published business service. You can change a business service in many ways, and how you change the business service depends on the business service design and the type of change that is required. Any change to a business service should be determined as part of the design process. Business service methods can call business functions, database operations, or another business service.

6.1.2.1 Calling a Business Function

You can create business service methods that call business functions. A business function is an encapsulated set of business rules and logic that can be reused by multiple applications. Business functions provide a common way to access the JD Edwards EnterpriseOne database. A business function performs a specific task. You use the business service foundation Business Function Call Wizard to create a business function call.

6.1.2.2 Calling a Database Operation

You can create business service methods that call database operations. Database operations include query, insert, update, and delete. You use the business service foundation Database Call Wizard to create these business services.

6.1.2.3 Transaction Processing

Transaction processing is a way to update the JD Edwards EnterpriseOne database. A transaction is a logical unit of work performed on the database to complete a common task and maintain data consistency. The database is updated when a transaction is either automatically or manually committed. The business service framework provides two types of default transactions: manual commit connection and auto commit connection.

For a single manual commit transaction, the default behavior is to scope all processing within the published business service method. If any operation within this scope fails, all operations are rolled back, and the published business service method throws an exception. This behavior is recommended when you commit multiple records to multiple tables.

For a single auto commit transaction, the default behavior is for each operation to commit or roll back immediately, which means that each table update within each business function call is either committed or rolled back immediately. This behavior is recommended for queries for which no transaction is needed or when you commit a single record to a single table.

When you are deciding which type of connection to use, you should always consider the business function behavior.

Default transaction behavior should cover most scenarios, but you can define a business service method that explicitly manages transactions. When determining whether a business service requires explicit transaction processing, you should review current JD Edwards EnterpriseOne functionality in the application. If the application uses explicit transaction processing, you should carefully review whether the business service should handle transaction processing the same way.

The Business Service Development Methodology guide provides a detailed discussion about transaction processing. In addition, the chapters pertaining to creating a published business service and creating a business service provide an overview of creating a transaction.

See also:

"Transaction Processing, Auto Commit" in the JD Edwards EnterpriseOne Tools Business Services Development Methodology Guide.

6.1.3 Business Service Properties

Business service properties provide a way for you to change a value in a business service method without changing the method code. A business service property consists of a key and a value. The key is the name of the business service property and cannot be changed. Business service properties are OMW objects. You can use OMW or the Business Service Property Admin program (P951000) to create and maintain them.

6.2 Creating a Custom Published Business Service

JD Edwards EnterpriseOne provides reference implementations that you can use as a model for creating a published business service. The reference implementations are for reference only and are not intended to be used in a production environment. The following steps provide how-to information for creating a custom published business service that can be exposed as a web service:

  1. Determine whether to create a new published business service or extend an existing published business service.

  2. Create a new OMW object for the published business service.

  3. Add classes to the published business service object.

    • Create published business service class.

      – Name the published business service class.

      – Create a transaction.

      – Name the published business service methods.

    • Create value object classes.

      – Create business function value object classes.

      – Name the input value object classes.

      – Name the response value object classes.

      – Use valid data types.

    • Create database operation value object classes.

      – Name the input value object classes.

      – Name the response value object classes.

      – Use valid data types.

  4. Add business logic.

    • Call business services.

    • Handle errors.

    • Format data.

  5. Test the published business service.

6.3 Testing a Published Business Service

You use tooling provided by JDeveloper to test and debug published business service methods. The published business service class is generated to a web service described in Web Services Description Language (WSDL) format and run on a J2EE server (OC4J) embedded within JDeveloper.

After the published business service is tested as a web service, you verify that the WSDL is compliant. You use JDeveloper for this task.

See Also:

  • Oracle JDeveloper Guide, http://www.oracle.com/technology/index.html.

6.4 Creating a Custom Business Service

JD Edwards EnterpriseOne provides reference implementations that you can use as a model for creating business services that are specific to your interoperability requirements. The following steps provide how-to information for creating a custom business service:

  1. Determine whether to create a new business service or modify an existing business service.

  2. Create a new OMW object for the business service.

  3. Add classes to the business service object.

    • Create a business service class.

      – Name the business service class.

      – Create a transaction, if necessary (IConnection objects).

      – Declare the business service public methods.

    • Create the internal value object class.

      – Name the internal value object class.

      – Transform data types.

  4. Add business service logic.

    • Create a business function call.

    • Create a database call.

    • Call existing business service methods.

    • Use business service properties.

    • Handle errors.

    • Format data.

6.5 Deploying the Business Services Server to the Integrated WebLogic Server

JDeveloper 11g includes the integrated WebLogic server. For convenience, the deployment profiles are automatically created while invoking JDeveloper11g from within OMW.

The deployment profile is created both at the JDeveloper project level as well as the JDeveloper application level.

A project level deployment profile is created for creating a WAR file and deploying it to the Integrated WebLogic server to test each project individually along with its dependent projects.

To deploy the business services server to the integrated WebLogic server:

  1. Open the appropriate project, click Properties, and then click Deployment.

    A WAR deployment profile already exists.

  2. Select the Deployment profile you want to edit, and then click Edit.

    The Edit WAR Deployment Profile Properties page displays.

  3. Edit the profile.

  4. From File Groups, click Web Files, and then click Contributors.

  5. In the Contributors section, click Add, then Browse, and then select the folder <E1Install>/system/classes/ConsumerBSS.

  6. In the Filter section, select the Presence of web.xml file option.

  7. In the WEB-INF/lib section, click Contributor, and then select the SBFProjects library.

  8. In the Filter section, select the Presence of the E1 Specific Jar Files.

  9. In the Filter section, click Target Connection, and then select the Integrated WebLogic server.

  10. When the deployment profile is ready, rebuild the entire project. Deploy the project to the Integrated WebLogic server.

6.6 Using a Deployment Profile for JDeveloper Application Level

To use a deployment profile for JDeveloper application level:

  1. From the Application Properties form, click Deployment.

    The BSSV_EAR deployment profile displays.

  2. Click the BSSV_EAR profile, click Edit, and then make the necessary edits.

  3. On the Application Properties form, select the non-dependent WAR modules that are deployed as war files within the BSSV_EAR.ear file.

  4. Select the war modules that you want to deploy to the server independently with their own context root.

  5. Click Platform, click Target Connection, and then select the IntegratedWebLogic Server.

  6. Click File, and then click Save.