This chapter contains the following topics:
The JD Edwards EnterpriseOne J2EE Connector Architecture (JCA) resource adapter enables Java2 Platform, Enterprise Edition (J2EE) components to use a standard interface to connect to the JD Edwards EnterpriseOne system. A resource adapter is a system-level software driver that enables J2EE components to communicate with a back-end enterprise information system (EIS) through a JCA-compliant application server when a resource adapter for the specific EIS is deployed to the server. J2EE components consist of Servlets, JavaServer Pages (JSPs), and Enterprise JavaBeans (EJBs).
J2EE components and applications built with J2EE components can execute business functions through the JD Edwards EnterpriseOne JCA resource adapter. JD Edwards EnterpriseOne business functions are accessed through the JCA standard client interface, the Common Client Interface (CCI). The JD Edwards EnterpriseOne JCA resource adapter is fully compliant to the Java2 Platform, Enterprise Edition (J2EE) JCA 1.0 Specification and should work with any application server that is J2EE 1.4 certified.
Note:
Some application servers are known to not be J2EE 1.4 certified but they support some J2EE 1.4 features, including JCA 1.0. Check with the application server vendor to determine whether the application server supports JCA1.0.See Also:
J2EE Connector Architecture, http://java.sun.com/j2ee/connector/.
The JCA 1.0 Specification identifies optional features for developing a resource adapter. This table addresses the level of support that the JD Edwards EnterpriseOne JCA resource adapter provides for the optional features identified in the JCA 1.0 Specification.
| Feature | Level of Support |
|---|---|
| Transactions | The JD Edwards EnterpriseOne JCA resource adapter is classified as an XA Transaction resource adapter. The JD Edwards EnterpriseOne JCA resource adapter permits either no transactions during business function calls, transactions local to JD Edwards EnterpriseOne during those same calls (local transaction), and one-phase commit (1PC) XA transactions (transactions that span multiple enterprise information systems). |
| Client Interface | The JD Edwards EnterpriseOne JCA resource adapter supports the optional common client interface (CCI), which is modeled after the Java Database Connectivity (JDBC) client API. This relatively simple Java API should significantly reduce the learning curve for using the JD Edwards EnterpriseOne JCA resource adapter. |
| Reauthentication | The JD Edwards EnterpriseOne JCA resource adapter does not support the switching of a set of JD Edwards EnterpriseOne user credentials on an existing JD Edwards EnterpriseOne user session. User credentials are usually a concern of the application server and should not affect client development. |
| Input/Output Records | The JD Edwards EnterpriseOne JCA resource adapter supports the MappedRecord interface, which is a data type of key-value pairs. The MappedRecord interface is further discussed in the Input/Output Data section of this document. The CCI interfaces IndexedRecord and ResultSet are not supported as they are not relevant to the type of output from business functions. |
| Authentication | The JD Edwards EnterpriseOne JCA resource adapter supports BasicPassword authentication, which indicates to the application server how to handle container-managed signon. The resource adapter does not support any other form of authentication, such as Kerberos authentication through the GenericCredential interface. The Signon Types section of this document provides more information about authentication with the resource adapter. |
| ManagedConnectionFactory Properties | The JCA Specification identifies these properties as standard; however, these properties are optional properties for the ManagedConnectionFactory class, which is the main class configured with JD Edwards EnterpriseOne specific properties during deployment of the resource adapter:
The JD Edwards EnterpriseOne JCA resource adapter supports the UserName and Password properties, as the other properties are either irrelevant properties or are configured elsewhere in the resource adapter. The Deployment Settings section of this document addresses other properties that are defined by the JD Edwards EnterpriseOne JCA resource adapter. Note: The deployment tool of the particular J2EE application server might list these properties as configurable for the resource adapter. The JD Edwards EnterpriseOne JCA resource adapter does not use values that you assign to these properties (other than that for UserName and Password). |
| Number of Deployed Resource Adapters | The JCA Specification allows for the possibility of deploying the same resource adapter multiple times on a given application server. This provides for potential connectivity to multiple versions of the same EIS for a one resource adapter-to-many-EIS version ratio. The JD Edwards EnterpriseOne JCA resource adapter supports the deployment of only one JD Edwards EnterpriseOne JCA resource adapter per application server (essentially one resource adapter per virtual machine).
Note: You can install different JCA resource adapters (those other than for JD Edwards EnterpriseOne) on the same application server. |
| Non-Managed Scenario | The JD Edwards EnterpriseOne JCA resource adapter must be used with an application server or an application client. If you want to access JD Edwards EnterpriseOne business functions through Java outside of an application server or application client, you should use the Java connector directly. |
See Also:
JCA Java documentation (APIs), http://java.sun.com/j2ee/apidocs-1_0-fr/api/index.html.
The packaging of a resource adapter is defined in the JCA 1.0 Specification. However, because some application servers require additions to the standard Resource Adapter Archive (RAR) file, it is not possible to distribute a single RAR file that can be deployed to all application servers. Consult the application server documentation for instructions on how to use the assembly tool and to understand what additional components might be required for a resource adapter to be operational with the application server. Typically, an additional deployment descriptor is required. Additional information required by an application server is usually for performance tuning and for configuration settings.
A RAR file is a file that is in Java Archive (JAR) File Format with a .rar extension instead of a .jar extension. The file structure for a RAR file is:
/META-INF/ra.xml
/<all necessary JAR files>
The ra.xml file is the standard resource adapter deployment descriptor and must be put in the META-INF directory of the RAR file. The ra.xml file must be named exactly ra.xml. The ra.xml file for the JD Edwards EnterpriseOne JCA resource adapter is provided in the system/classes/samples directory on the JD Edwards EnterpriseOne CD. All other JAR files go in the root directory of the RAR file. The JAR files are provided in the system/classes directory on the same CD. The required resource adapter JAR files include:
ApplicationAPIs_JAR.jar
ApplicationLogic_JAR.jar
Base_JAR.jar
BizLogicContainer_JAR.jar
BizLogicContainerClient_JAR.jar
BusinessLogicServices_JAR.jar
castor.jar
commons-httpclient-3.0.jar
commons-logging.jar
Connector.jar
Generator.jar
j2ee1_3.jar
JdbjBase_JAR.jar
JdbjInterfaces_JAR.jar
JdeNet_JAR.jar
jmxremote.jar
jmxremote_optional.jar
jmxri.jar
log4j.jar
ManagementAgent_JAR.jar
Metadata.jar
MetadataInterface.jar
owra.jar
PMApi_JAR.jar
Spec_JAR.jar
System_JAR.jar
SystemInterfaces_JAR.jar
xerces.jar
xmlparserv2.jar
JDBC driver jar files supplied by the database vendor.
Note:
Only use the versions of these JAR files that come with the JD Edwards EnterpriseOne distribution.When the RAR file is finally created, the META-INF directory of the RAR file might contain a Manifest.mf file. The Java JAR tool usually creates the Manifest.mf file automatically. The Manifest.mf file complies with the JAR file format, and it is acceptable for the Manifest.mf file to be in the RAR file.
The methods and tools for configuring and deploying a resource adapter vary between application servers and even between versions of the same application server. Consult the application server documentation for information about how to configure and deploy a resource adapter. Two separate methods exist for deploying a resource adapter. The first method is deploying the resource adapter as a standalone resource adapter. This permits all applications deployed on the application server to access the same resource adapter. The second method involves packaging the resource adapter within an enterprise application (EAR) file. This permits only those components in the EAR file to have access to the resource adapter. The sample applications provided with the JD Edwards EnterpriseOne JCA resource adapter use the second method.
Additional settings required for the JD Edwards EnterpriseOne JCA resource adapter to be deployed and to operate correctly include:
Security permissions.
jdeinterop.ini settings.
jdbj.ini settings.
jdelog.properties settings.
CLASSPATH settings.
Configurable properties.
Java naming directory interface settings.
Note:
Only one JD Edwards EnterpriseOne JCA resource adapter can be deployed in standalone mode per application server.The JCA 1.0 Specification defines the standard Java security permissions that must be granted to all resource adapters by an application server. The JD Edwards EnterpriseOne JCA resource adapter needs additional security permissions to operate. These permissions are listed in the deployment descriptor (ra.xml file). Most application servers dynamically grant these permissions to the resource adapter during deployment. Some application servers have other methods of granting the resource adapter additional permissions, including modifying a Java security policy file, which might require that you restart the application server to take effect.
If the application server does not dynamically grant the security permissions to a resource adapter based on the contents of the deployment descriptor, you need to grant the resource adapter the permissions listed in the security-permission-spec elements of the deployment descriptor. If the application server throws a SecurityException while running an application associated with the JD Edwards EnterpriseOne JCA Resource Adapter, it is possible that the necessary security permissions are not being granted to the resource adapter.
Because the resource adapter is built on top of the Java connector, it is necessary to configure the appropriate settings in the jdeinterop.ini file to make the Java connector operational. The resource adapter introduces no new settings into the jdeinterop.ini file.
You must set up the jdbj.ini file.
See JD Edwards EnterpriseOne Tools Release Tools Reference Guide.
See JD Edwards EnterpriseOne Tools Release HTML Web Server Reference Guide.
The JCA 1.0 Specification permits resource adapter-specific logging messages to be sent to a separate log file, which can be configured according to the application server (see the application server documentation). The messages that are sent to this log file are redundant to and are a subset of the messages that are sent to the log file defined in the jdelog.properties file. This redundancy is an intentional JD Edwards EnterpriseOne JCA resource adapter design decision for this reason:
The JCA logging mechanism does not provide a method for logging messages from the connector on which the resource adapter is built. The logging properties file permits all logging messages from the connector as well as the resource adapter to be logged in a central location.
The JD Edwards EnterpriseOne JCA resource adapter requires that the complete path to the jdelog.properties file be placed in the server's CLASSPATH. This path cannot include the name of the file, and the path must end with a slash, which designates that the last item in the path is a directory and not a file. The name of the properties file is required to be jdelog.properties. The logging mechanism looks for the logging properties file in all directories in the CLASSPATH.
The JDBC driver for the JD Edwards EnterpriseOne database must be in the server's CLASSPATH so that the proper database connections can be made.
Note:
Some servers require all of the JAR files within the resource adapter RAR file to be placed in the server's CLASSPATH. If you encounter a NoClassDefFoundError while running a Web application that is using the resource adapter, try putting all of these JAR files in the server's CLASSPATH and restarting the server. Consult the server documentation for further ClassLoader issues.The JD Edwards EnterpriseOne JCA resource adapter deployment descriptor (ra.xml file) contains properties that must be assigned values specific to the environment. This table identifies the configurable properties and describes the information required.
| Property | Required Information |
|---|---|
| owVersion | The version of JD Edwards EnterpriseOne to which the resource adapter connects. This property is for display purposes only and can contain any value. The value you enter in this property is not validated against the JD Edwards EnterpriseOne installation. |
| username | Use this property for a JD Edwards EnterpriseOne user when neither the container nor the application supplies a set of JD Edwards EnterpriseOne user credentials. |
| password | Use this property for a JD Edwards EnterpriseOne user when neither the container nor the application supplies a set of JD Edwards EnterpriseOne user credentials. |
| environment | It is possible in a resource adapter web application to map a user's web credentials to a set of JD Edwards EnterpriseOne user credentials. This mapping, which is called container-managed signon, prevents the user from having to present different credentials multiple times while using a single web application.
Container-managed signon maps a given user name and password to a JD Edwards EnterpriseOne user name and password. Container-managed sign-on mapping is specific to each application server. For JD Edwards EnterpriseOne, the environment property is used to add a valid JD Edwards EnterpriseOne environment to the user name and password mapped by the application server, which permits proper JD Edwards EnterpriseOne signon. If you use container-managed signon, you must assign a value to this property. |
| role | In addition to user name, password, and environment, JD Edwards EnterpriseOne signon requires a role. The role property has a default value of *ALL, which enables the user to assume all valid roles for the JD Edwards EnterpriseOne user name. You do not need to assign a value for role if this is the value you want to use. |
Consult the documentation for the application server to determine if other deployment settings are required.
For communication between the web application and the JD Edwards EnterpriseOne JCA resource adapter, the web application must perform a Java Naming and Directory Interface (JNDI) lookup of the ConnectionFactory of the resource adapter. You are allowed to configure multiple ConnectionFactory instances for each resource adapter. This permits setting different values for the configurable properties listed in the previous section. The web application obtains a JD Edwards EnterpriseOne connection and interacts with JD Edwards EnterpriseOne through the ConnectionFactory. The method of assigning a JNDI name to the ConnectionFactory for the JD Edwards EnterpriseOne JCA resource adapter is specific to and documented by the application server.
When you add a ConnectionFactory through the application server, you are provided with a method for assigning values to the configurable properties for each ConnectionFactory.
The Common Client Interface (CCI) is the JCA-recommended client API for all resource adapters. The JD Edwards EnterpriseOne JCA resource adapter provides an implementation of CCI as the client interface.
This example code shows how to implement a CCI for the JD Edwards EnterpriseOne JCA resource adapter. In the example code, the elements in quotes have descriptive names and must have values valid to the environment in a real Java class. The line numbers in the example code are not part of the code but are for reference in subsequent paragraphs.
import com.jdedwards.system.connector..dynamic.jcaplugin.
ImageBSFNInteractionSpecImpl;
import com.jdedwards.system.jca.cci.ConnectionSpecImpl;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.resource.ResourceException;
import javax.resource.cci.Connection;
import javax.resource.cci.ConnectionFactory;
import javax.resource.cci.Interaction;
import javax.resource.cci.MappedRecord;
import javax.resource.cci.RecordFactory;
import javax.resource.cci.ResourceWarning;
public class SomeClass {
public void someMethod() {
try {
// get the naming context
Context nc = new InitialContext();
// lookup the connection factory
ConnectionFactory conFact = (ConnectionFactory)nc.lookup("Resource
Adapter JNDI Name");
//1. create a ConnectionSpec
ConnectionSpecImpl conSpec = new ConnectionSpecImpl("username",
"password", "environment", "role");
//2. get the Connection to JD Edwards EnterpriseOne
Connection con = conFact.getConnection(conSpec);
// create an Interaction
Interaction ix = con.createInteraction();
// create and populate the InteractionSpec
OWBSFNInteractionSpecImpl ixSpec = new OWBSFNInteractionSpecImpl();
ixSpec.setBusinessFunction("Business Function Name");
// get a RecordFactory
RecordFactory rf = conFact.getRecordFactory();
//3. create the input MappedRecord
MappedRecord inputRecord = rf.createMappedRecord("any descriptive
name");
//4. populate the input MappedRecord with the input values
inputRecord.put("Business Function Parameter Name",
" Business Function Parameter Value");
//5. execute the Business Function, putting the results in the output
// MappedRecord
MappedRecord outputRecord = (MappedRecord)ix.execute(ixSpec, inputRecord);
// get results
Object value = outputRecord.get("Business Function Parameter Name");
// get Business Function warnings, if any
ResourceWarning warning = ix.getWarnings();
// close the Interaction
ix.close();
// close the Connection
con.close();
} catch (ResourceException e) {
// handle resource adapter-related Exceptions here
} catch (NamingException e) {
// handle JNDI-related Exceptions here
}
}
}
The JD Edwards EnterpriseOne JCA resource adapter provides these types of JD Edwards EnterpriseOne signons:
Container-managed signon
Component-managed signon
When container-managed signon is used, the application server maps a web application user to a given JD Edwards EnterpriseOne user. In this case, JD Edwards EnterpriseOne user credentials are not provided in the CCI code. If you use container-managed signon, line 1 of the example code would not exist, as you do not need to create an instance of the ConnectionSpecImpl class. Line 2 of the example code would be changed to this:
Connection con = conFact.getConnection();
When component-managed signon is used, the code provides specific JD Edwards EnterpriseOne credentials (either through coding specific credentials or by obtaining JD Edwards EnterpriseOne credentials through user entry in the web application) to the JD Edwards EnterpriseOne JCA resource adapter for JD Edwards EnterpriseOne signon. In the example code, lines 1 and 2 illustrate component-managed signon. In line 1 of the example code, an instance of the ConnectionSpecImpl class is first created with the JD Edwards EnterpriseOne user credentials. That instance is then passed to the getConnection method.
Component-managed signon is also known as application-managed signon.
The import statements at the top of the example code illustrate that most of the classes that you use to interact with the JD Edwards EnterpriseOne JCA resource adapter are JCA classes (those classes in the javax.resource package and sub-packages) and not JD Edwards EnterpriseOne-specific implementations of JCA interfaces. JD Edwards EnterpriseOne software provides these implementation classes:
ConnectionSpecImpl
xxxxInteractionSpecImpl
The ConnectionSpecImpl class supplies the required JD Edwards EnterpriseOne user credentials to the getConnection method. The ConnectionSpecImpl class is one of the signon types. Line 1 in the example code shows how to use the ConnectionSpecImpl class.
The purpose of the xxxxInteractionspecImpl class is to establish the necessary business function information before execution in JD Edwards EnterpriseOne. The xxxxInteractionSpecImpl classes vary, depending on the type of business function spec source. The business function spec source is a file or location that describes a business function. Each implementation class, which is a concrete class of the javax.resource.cci.InteractionSpec interface, includes methods that set values. These setter methods must be called and given values before executing the business function through the resource adapter.
The ImageBSFNInteractionSpecImpl implementation class gets the business function spec from an XML image file, which must be generated by the dynamic Java connector beforehand.
Class: com.jdedwards.system.connector.dynamic.jcaplugin.ImageBSFNInteractionSpecImpl
Method: setBusinessFunction(String value)
Sets the exact name of the business function.
Method: setImageFilename(String value)
Sets the complete path and filename of the dynamic Java connector JD Edwards EnterpriseOne spec image that contains the definition of the corresponding business function.
The OWBSFNInteractionSpecImpl implementation class gets the business function spec directly from a call to JD Edwards EnterpriseOne. This method might take a little longer to execute a business function the first time the business function is called. The business function is stored in memory, and execution should be quicker in subsequent calls.
Class: com.jdedwards.system.connector.dynamic.jcaplugin.OWBSFNInteractionSpecImpl
Method: setBusinessFunction(String value)
Sets the exact name of the business function.
The MappedRecordImpl class handles both sending input data to the resource adapter and receiving the output data that is the result of executing the business function. Lines 3 and 4 of the example code illustrate inputting data, and line 5 illustrates obtaining the output data. A MappedRecord is a correlation of key/value pairs. The key represents the exact business function parameter name, and value defines the key.
Input data for values can be supplied in one of these ways:
Use a string.
Use a native Java data type.
The JD Edwards EnterpriseOne JCA resource adapter examines the input data on a parameter-by-parameter basis. If the input data type is string, the resource adapter attempts to convert the input data to the appropriate Java data type for the specified parameter. If both the actual parameter type and the input data are string, the resource adapter passes the input data through unchanged. If the input parameter is a native Java data type, the resource adapter passes the input data through unchanged.
If the native Java data type is incorrect or if the parameter name is invalid for the given business function, the resource adapter throws an exception.
This table lists the business function types and their corresponding native Java data type:
| JD Edwards EnterpriseOne Data Type | Native Java Data Type |
|---|---|
| ID | java.lang.Integer |
| char (length of only 1) | java.lang.Character |
| JDEDATE | java.util.Date |
| Calendar | com.jdedwards.base.datatypes.JDECalendar |
| MATH_NUMERIC | com.jdedwards.system.lib.MathNumericImpl |
| char (variable length) | java.lang.String |
The output of all business functions result in the data in the MappedRecordImpl being in the native Java data types. If you prefer only string-formatted output, you can make this call on the output MappedRecordImpl for each parameter retrieved:
String value = outputRecord.get("parameter name").toString();
Message logging for the JD Edwards EnterpriseOne JCA resource adapter is controlled by the jdelog.properties file.
The parent Exception class for all exceptions thrown by the JD Edwards EnterpriseOne JCA resource adapter is javax.resource.ResourceException.
See Also:
JCA Javadoc, http://java.sun.com/j2ee/apidocs-1_0-fr/api/index.html.
The samples supplied with the resource adapter illustrate how to use the resource adapter's API, as well as the JCA API, and how to demonstrate the functionality of the resource adapter. Address Book Query, Sales Order Entry, and Purchase Order Entry are included samples. The source code along with the compiled classes are delivered on the JD Edwards EnterpriseOne Java Server CD in the system/classes/samples directory in the JCASamples.ear file and the JCASamples_WebSphere.ear file.
The sample applications consist of a group of servlets, which provide the HTML for the display of the samples, and a group of stateful session Enterprise JavaBeans (EJBs) that access the JD Edwards EnterpriseOne JCA resource adapter. The resource adapter is bundled inside the .ear files and is only available to the sample applications when deployed to the application server.
These customizations must be performed to the .ear file before it can function correctly.
JDBC driver .jar file.
Configuration files.
Samples for the application server.
The JDBC driver .jar file supplied by the JD Edwards EnterpriseOne database vendor must be packaged inside the .ear file. Since the .ear file is in a Zip format, you can use a Zip program to add the necessary files. Place the JDBC driver .jar files in the root directory of the .ear file (no path for those files). The CLASSPATH in the manifest.mf file on the .ear file includes the expected filenames for the JDBC .jar files for three database vendors without actually being included in the driver files themselves:
SQL Server: msbase.jar, msutil.jar, mssqlserver.jar, sqljdbc.jar.
Oracle: classes 12.jar, ojdbc.jar, ojdbc4.jar, ojdbc5.jar.
DB2 for IBM i: jt400.jar.
If the file names of the JDBC driver .jar files are different, add those file names to the manifest.mf file that is located inside the meta-inf directory of the JCA Samples RAR.rar file within the sample application.ear file you are using. Be sure to preserve the meta-inf path for the manifest.mf file when you add it back into the file.
You must configure these files:
jdbj.ini
jdeinterop.ini
jdelog.properties.
These configuration files are in the config directory of the sample application EAR file. After you customize the settings, be sure to place the files back into the EAR file in the config directory.
A generic JCASamples.ear file and a WebSphere 5.x-specific JCASamples_websphere.ear file are provided. The application server might need additional information for some of the components contained in the EAR file. This is a list of the sample components:
JCASamplesEJB.jar
A JAR file that contains the Enterprise JavaBean (EJB) classes used by the samples.
JCASamplesRAR.rar
A rar file that contains only the resource adapter deployment descriptor. The dependent JAR files for the resource adapter are contained in the parent directory of the EAR file, as they need to be used by the entire application.
JCASamplesWeb.war
A WAR file containing the servlets for the sample applications.
If you use the generic JCASamples.ear file to deeply the sample applications to the application server, and they do not operate correctly, you might need to unpack each of the files individually (.ear, .jar, .rar, and .war files) and repack them with the application server's assembly tool. This step usually enables the tool to place new files and information in existing files that enable the application to operate correctly for that application server.
These general steps must be completed for deploying the sample applications to any application server:
Start the application server.
Start the administrative console (whatever application that ships with the application server that enables you to deploy applications).
Install the enterprise application.
Add a connection factory for the resource adapter with a JNDI name of OneWorldJCAAdapter (with that exact spelling).
Restart the application server.
The application server may require additional steps not listed here (see the application server documentation for deploying enterprise applications).
Use these steps to deploy the sample applications on WebSphere 5.x:
Start WebSphere.
Start the WebSphere Administrative Console.
Log on to the WebSphere Application Server Administrative Console using any ID.
On the WebSphere Administrative Console, expand the applications node on the left side of the screen, and then click the Install New Applications link.
Preparing for the Application Installation appears on the right side of the screen.
In the Preparing for the application installation portion of the screen, click Browse, and then select JCASamples_WebSphere.ear file.
Click Next.
Continue to click Next on all successive screens until the final Summary screen presents a Finish button at the bottom of the screen. Accept the default values provided on each of the screens without altering any of them.
On the final Summary screen, click Finish.
WebSphere automatically generates the necessary EJB deployment code.
At the bottom of the screen, after the notice that the Application JCA samples installed successfully, click the Save to Master Configuration link.
A Message box (indicating that changes have been made to the local configuration) and an Enterprise Application Save section that includes a Save to Master Configuration box appear.
In the Save to Master Configuration box, click the Save button.
You are returned to the main screen.
On the left side of the main screen, click the Enterprise Applications link from the menu.
A list of the installed applications appears on the right side of the screen.
On the right side of the screen, click JCASamples from the list that appears under Enterprise Applications.
In the Related Items area at the bottom of the next screen, click the Connector Modules link.
On Connector Modules, click JCASamplesRAR.rar.
On the screen with a Configuration tab, scroll to the Additional Properties area and click the Resource Adapter link.
On the next screen with a Configuration tab, scroll to the Additional Properties area, and then click the J2C Connection Factories link.
On the J2C Connection Factories screen, click the New button to establish a new J2C Connection Factory.
Under the Configuration tab on the New screen, enter any value for the Name field and OneWorldJCAAdapter for the JNDI name.
The value you enter for the Name field is used for display purposes only.
Scroll to the bottom of the screen, and then click the OK button.
In the Message box at the top of J2C Connection Factories screen, click the Save link.
In the Save to Master Configuration area on the Save screen, click the Save button.
From the menu bar (at the top of the screen), click Logout.
Stop and restart the sever to make the application is available to run.
After you configure and deploy the sample applications, you can run each of the sample applications, provided that the JD Edwards EnterpriseOne Server you are accessing is operational. Use these URLs to access the samples:
AddressBook Query: http://<app http://<app server name>|<app server port>/JCASamplesWeb/ABLogin
SalesOrder Entry: http://<app server name>|<app server port>/JCASamples Web/SOLogin
PurchaseOrder Entry: http://<app server name>|<app server port>/JCASamplesWeb/POLogin
If the system is not working, use this checklist to ensure you have the proper setup:
The directory location of the jdelog.properties file must be in the server's CLASSPATH.
For example, if the jdelog.properties file is in this location:
C:\JCA\logs\jdelog.properties
you must have this entry in the server's CLASSPATH:
C:/JCA/logs/
Be sure to include a slash at the end of the path to indicate that logs is a directory and not a file. When you make a change to the server's CLASSPATH, you must restart the server.
Some servers read the <security-permission-spec> element of the resource adapter's deployment descriptor (the ra.xml file) and dynamically grant the resource adapter the security permissions listed in those elements.
If you are executing a resource adapter-based application and experience a java.xxx.xxxPermission Exception, you have to manually add the contents of the <security-permission-spec> elements to the server's policy file. Consult the server's documentation for the location and format for editing the policy file. You should be able to simply copy and paste the elements into the server's policy file. Any changes to the policy generally require a server restart to take effect.
If you make the changes and still experience Permission Exceptions, you might need to move some of the permission elements that you copied from the resource adapter domain in the policy file to the default domain in the policy file. This is because the resource adapter classes, especially if present in the server's CLASSPATH, might reside in the default domain and not the resource adapter domain.