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.
When you generate Java implementations for components in an assembly diagram, the generated Java implementations should be used as a launch point to call other Java classes.
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:
You should avoid modifying module dependencies outside the dependency editor.
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.
Artifacts in a library are public. Artifacts in a module are private. Designers of WID applications should organize artifacts by taking into consideration logical function and visibility. For example, related data types that are used by various pieces of a system should be placed into a library. Other modules may then easily reuse this library. Only one copy of each artifact needs to be created and maintained using this method. Likewise, related business logic features of the application should be grouped into modules. Componentizing an application in this way will yield a more flexible, easily maintained application. Adding new features to the application will also be easier.
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.
Take particular care when you organize artifacts into namespaces. Namespaces should not overlap between dependent projects. For example, if a business object exists in a module, {http:/mytns}Customer, and another business object exists in a library {http://mytns}Address, then you might be tempted to add the library as a dependent of the module. However, if you yield to that temptation, "Address" will not resolve at run time, because the program will only look for one source for a particular type of artifact in each namespace. Keeping unique namespaces for like artifacts, and keeping these artifacts in one project will help avoid these situations.
Do not modify the generated J2EE module. Direct modifications might be overwritten the next time the integration module project is built in WebSphere Integration Developer. Also, direct modifications to this module can result in an invalid application.
If the J2EE staging projects are manually deleted for a module, then all staging projects may not be re-created after saving an editor (for example, the assembly editor). This problem only arises when auto-build is turned on. Only artifacts that have changed will have their deployment code regenerated as the build incrementally processes deltas.
To solve this problem, perform a clean build.
Related information