Body

InfoSphere Master Data Management operational server v11.x OSGi best practices and troubleshooting guide

Note: This preview only covers the initial set up of the MDM Workbench. The full developerWorks article has now been published and contains these additional topics:

• Bundle project build path
• Exporting services from composite bundles
• Deploying a CBA composition unit extension
• Class loaders explained… cyclical dependencies
• Troubleshooting

Introduction

The goal of this article is to show best practices and optimal development practices for developing with the InfoSphere MDM operational server. We will discuss common OSGi patterns, troubleshooting, including failures and resolution, as well as how to best deploy MDM composite bundle (CBA) extensions.

The InfoSphere MDM version v11 operational server is based on an enterprise OSGi architecture, which is modular in nature. The benefits of a modular architecture application design include reducing complexity, reducing time to delivery, and increasing serviceability. The Java EE infrastructure leveraged in previous versions of InfoSphere MDM had limited ability to enforce or encourage a modular design.

The advantage of a modular MDM application is to allow customization to be deployed without having to alter the core MDM application. Instead, customizations are attached in the form of extensions to the core MDM application. This is done using composite bundles, or CBA files.


 

Optimal workspace operational server configurations

The InfoSphere MDM Workbench is a tool that supports development of customizations and extensions to MDM operational server. The MDM Workbench allows you to define the desired data model and transactions and then generates the code required to implement the MDM Server extensions.

When using workbench to build and deploy your MDM customizations and extensions, there are a few workspace configurations to consider for achieving the best performance and development experience.

1. Workbench workspace server definition settings
   
   Publishing CBAs from the MDM Workbench using the "Run server with resources within the workspace" option, sometimes called a "loose config" option, is not desired because it might cause the workspace and the server deployment to be out of sync. Use of this option often results in CBA deployment errors where the MDM EBA application fails to start. To resolve this, you must manually remove the CBA deployment using the WebSphere Application Server administrative console to return the application back to its original state.
   
   The optimal configuration is to use the "Run server with resources on Server" publishing option. Although this option will be slower, it is more stable. This option is a true reflection of a deployment to the production environment because the CBA is physically built, packaged, and deployed in the internal bundle repository of WebSphere Application Server.
   
   The second server definition option is to avoid publishing changes automatically to the server. Since publishing can be a time consuming operation, we want to avoid doing this for every simple changes we do in the workspace. The option to publish only when we have sufficient changes is ideal.
   
   -Double click (or Right click and select Open) to open the server’s definition.
   
   
   
   
   
   
   
   
   
   Note: Un-deploy any previously deployed CBA assets from the server prior to switching the publishing settings.
   
   
   Finally, we recommend “Start server with a generated script” to be unchecked to allow proper MDM logging to occur.
   
   
   
   
   
   
   
   
   
    

2. Run server in debug mode
   
   Avoid re-publishing the CBA and bundle changes to the server for simple Java class changes.  We can opt to run the server in “debug mode” and leverage the hot swap of Java code (also known as the “Hot Method Replace”) feature.  When running the application server in debug mode, hot method replace allows most application changes to be picked up automatically without requiring a republish, application restart or server restart.  There are cases where we cannot simply rely on the hot method replace.  Application structure changes such as OSGi blueprint changes, manifest change, CBA manifest changes and code refactoring will still require a republish.
    
3. Remove legacy applications and services
   
   If your MDM implementation doesn’t require the use of the Legacy UIs and/or legacy JAX-RPC web services, you can choose to uninstall these components from the application server.  This will increase the startup performance of the application server and also reduce memory consumption. 
   
   The MDM JAX-RPC web services are deployed as a CBA extension.  Note that the JAX-RPC web services have been deprecated in InfoSphere MDM v10 and replaced by the new JAX-WS specification.  It is recommended to migrate your existing JAX-RPC web services implementation to the new specifications but this may not always be possible.
   
   Uninstalling JAX-RPC web services is as simple as removing the CBA extension from the composition unit of the InfoSphere MDM operational server. 
   
   1. In WebSphere Application Server Administrative Console, Navigate to Applications --> Application Types --> Business Level Applications, and select the MDM-Operational-server-EBA-E001. Then select com.ibm.mdm.hub.server.app_E001-0001.eba. See below:
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   2. Select ‘Extensions for this composition unit’.
   3. Select the ‘com.ibm.mdm.server.jaxrpcws.cba’ CBA currently attached to the EBA and click Remove.
   4. Save changes to master configuration file.
   5. Return to the previous screen and click ‘Update to latest deployment…’.
   6. Save changes to master configuration file.
    
4. Apply WebSphere interim fixes for performance improvements
   
   See the following InfoSphere MDM technote for more info.
   /support/pages/node/497397

Read more...