When developing business integration applications, you may need to work with resources such as JSP files, JAR files, Web projects, Java™ projects, and J2EE projects. This topic provides information to help you set up your projects and resources so that they can be successfully built and deployed to WebSphere® Process Server.
If the Web project is in another EAR file, then the JSP file is in another module, and imports and exports are required for it to work with services in another module.
Here is some sample JSP code that uses the stand-alone references in the module assembly:
com.ibm.websphere.sca.Service bankService = (com.ibm.websphere.sca.Service)com.ibm.websphere.sca.ServiceManager.INSTANCE.locateService("BankServicePartner"); => The "BankServicePartner" reference name comes from the sca.references file in the module (e.g. <reference name="BankServicePartner">...). This file will exist after creating a stand-alone reference in the wiring editor. com.ibm.websphere.sca.scdl.OperationType operationType = bankService.getReference().getOperationType("openAccount"); => We will use the operation type to get the DataObject types that need to be passed into the invoke operation com.ibm.websphere.bo.BOFactory factory = (com.ibm.websphere.bo.BOFactory) new com.ibm.websphere.sca.ServiceManager().locateService("com/ibm/websphere/bo/BOFactory"); => Standard way to obtain factory for creating business objects. commonj.sdo.DataObject input = factory.createByType(operationType.getInputType()); => create the proper kind of data object that the operation expects as input commonj.sdo.DataObject customer = input; => assume that we don't have a wrapped input, for now if(operationType.isWrapperType(operationType.getInputType())) { => In order to call the reference in this case, the wrapper defined in the interface's WSDL file must be passed in. So we create the wrapped data object and set it on the wrapper (the property name comes from the inlined schema in the WSDL file). customer = factory.createByType(operationType.getInputType().getProperty("customer").getType()); input.set("customer", customer); } customer.setString("firstName", "Bob"); customer.setString("lastName", "Smith"); customer.setString("address", "7 Holly Drive"); customer.setBoolean("isGold", true); customer.setInt("birthYear", 1976); => The above 5 lines set the attributes on Customer. commonj.sdo.DataObject output = (commonj.sdo.DataObject)bankService.invoke("openAccount",input); commonj.sdo.DataObject account = null; if(operationType.isWrapperType(operationType.getOutputType())) account = output.getDataObject("account"); else account = output; => The output returned may or may not be wrapped.
Best Practices: If you need to develop Java applications or import JAR files that will be used in a business integration module, you should create a Java project for the code and add a dependency on the Java project to the module that will be using the Java code.
The Java properties of the business integration library or module should not be altered because this may cause problems in deployment code generation. As a result, we do not recommend that you develop complex Java applications or import JAR files into a library or module in order to use them. Also, when generating Java implementations for components in an assembly diagram, the generated Java implementations should be used as a launch point to call other Java classes.
Note that the Business Integration view only shows Java implementations and interfaces that are used in an assembly diagram. They are listed under the module that uses them. If you need to work with Java projects you can switch to work in the Java perspective.
Switching to the Java perspective
Open the Java perspective by following these steps:
In the Java perspective, the two opened perspectives are shown at the top right corner of the Workbench window, you can switch to the Business Integration perspective by clicking the Business Integration perspective button, as shown in this image:
Best Practices: If you plan to use imports and exports in assembly diagrams, it is a good practice to put the business objects and interfaces that are used by the import and exports into a library so that they can be shared. Then, add a dependency on the library to all of the modules that use these common resources. Avoid copying the same business objects and interfaces into different modules to use them.
If you need to use a WSDL file in a module, copy it to the module. Optionally, copy the WSDL file to a library and, in the module, set a dependency on the library so that you can use the library's resources. If you tried to drag a WSDL file from another type of project, for example a Web project, an error message will prompt you to copy the WSDL to the module or library.
You should avoid modifying module dependencies outside of the dependency editor.
When you add a dependency on a library, Java project, or J2EE project, changes are made to the module's properties. That is, the module's properties are changed, as follows:
Use the dependency editor to manage project dependencies for your modules and libraries instead of editing their properties. There are important Java assumptions set in the properties of modules and libraries, so you should not modify the Java properties, for example, to change their source and output folders.
Related information