Search for the 2 classes on server, and replace with the temp fix and restart the server.
e.g.
find . -name "TCRMPartyComponent.class" -print
/opt/IBM/WebSphere/AppServer9.0/profiles/Node01/installedEBAs/com.ibm.mdm.hub.server-MDM116Instance_11.6.0.8/byValue/87f44ab3-3768-47d9-9ad3-84609f960921.31/31/com/dwl/tcrm/coreParty/component/TCRMPartyComponent.class
find . -name "TCRMPrivacyPreferenceComponent.class" -print
/opt/IBM/WebSphere/AppServer9.0/profiles/Node01/installedEBAs/com.ibm.mdm.hub.server-MDM116Instance_11.6.0.8/byValue/87f44ab3-3768-47d9-9ad3-84609f960921.37/37/com/dwl/tcrm/businessServices/component/TCRMPrivacyPreferenceComponent.class
However, if you want to deploy it properly, follow these steps :
1) Log on to the WebSphere admin console
2) Export EBA from server
Applications -> Assets
com.ibm.mdm.hub.server.app-<appName>.eba
Select the Export button and export the EBA
2) Extract bundles from the exported EBA
com.ibm.mdm.server.party.<version_date_timestamp>.jar
com.ibm.mdm.server.bizservices.<version_date_timestamp>.jar
3) replace the 2 classes in the extracted bundles with those provided
bundle: com.ibm.mdm.server.party.<version_date_timestamp>.jar
com.dwl.tcrm.coreParty.component.TCRMPartyComponent.class
bundle: com.ibm.mdm.server.bizservices.<version_date_timestamp>.jar
com.dwl.tcrm.businessServices.component.TCRMPrivacyPreferenceComponent
4) extract META-INF/MANIFEST.MF from both bundles
update MANIFEST.MF Bundle-Version to higher value at date_timestamp
replace META-INF/MANIFEST.MF with updated copy
rename the 2 bundles with new date_timestamp
5) Navigate to Environment->OSGi bundle repositories->Internal bundle repository
6) Click New and then select the new com.ibm.mdm.server.party.<version_date_timestamp>.jar
repeat for com.ibm.mdm.server.bizservices.<version_date_timestamp>.jar
7) Once the file has loaded click Review link then select "Synchronize changes with Nodes" and click Save followed by OK once the update has completed and then OK and the new bundle should be listed in the repository
8) Navigate to Applications->Application Types->Assets->com.ibm.mdm.hub.server.app-<appName>.eba
9) Click on "Update bundle versions in this application"
10) Change the com.ibm.mdm.server.party and the com.ibm.mdm.server.bizservices bundle versions into the versions loaded earlier and then click Preview followed by Create
11) Click the Review link then select "Synchronize changes with Nodes" and click Save followed by OK once the update has completed
12) Navigate to Applications->Application Types->Business-level applications->com.ibm.mdm.hub.server.app-<appName>.eba
13) Click the "Update to latest deployment..." button and hit OK
14) On the Blueprint resource references screen, select the Authentication Alias for datasources jdbc/DWLConfig and jdbc/DWLCustomer, and then Next then Next and Finish
15) Click the Review link then select "Synchronize changes with Nodes" and click Save followed by OK once the update has completed
16) Navigate to Servers->Server Types->WebSphere application servers
17) Select the server and click the Restart button
Tuesday, September 24, 2019
how to replace classes on server
Monday, September 23, 2019
BTM ITxRx Exception
Clearing the cache is something that is used to solve many issues that are not product defect. This includes your issue here. I think this case can be closed as there is no further action required here.
clearing WAS osgi cache is a known fix of this "Controller class loading issue"
Trace settings
*=info: com.dwl.*=warning: com.ibm.mdm.*=warning: com.ibm.mdm.server.config.*=info: com.ibm.mdm.common.brokers.*=info: com.ibm.mdm.mds.*=info: com.initiatesystems.*=info: com.dwl.base.report.mbean.TransactionDataListener=fine: WLM*=all: com.dwl.jmsadapter.mdb.*=info: com.dwl.base.requestHandler.*=info: com.ibm.ws.classloader.*=all
[9/11/19 13:20:20:978 EDT] 00001a91 TCRMCommonCom E com.dwl.base.exception.DWLDataInvalidException: [1001 FVERR 1102 The following is required: ReferenceNumber][1009 FVERR 102 EndDate must be after StartDate]
The only error that is of a concerns is this ..
[9/10/19 13:34:19:054 EDT] 00001e58 DWLExceptionU E java.lang.Exception: [Exception_DWLTxnBP_CannotLoadBeanController:] CDKCH2005E:The controller class cannot be loaded. Controller class = Controller Service not found for transaction: getPerson
at com.dwl.base.requestHandler.DWLTxnBP.processInquiryObject(DWLTxnBP.java:400)
at com.rbc.cdm.composite.compositeTxn.RbcBaseTxnBP.fireInquiryTransaction(RbcBaseTxnBP.java:192)
at com.rbc.cdm.composite.compositeTxn.RbcBaseTxnBP.getPerson(RbcBaseTxnBP.java:300)
at com.rbc.cdm.composite.compositeTxn.MaintainCDMPartyCompositeTxnBP.processRequest(MaintainCDMPartyCompositeTxnBP.java:697)
at com.rbc.cdm.composite.compositeTxn.MaintainCDMPartyCompositeTxnBP.execute(MaintainCDMPartyCompositeTxnBP.java:185)
at com.dwl.base.requestHandler.DWLTxnProcessor.processTx(DWLTxnProcessor.java:98)
at com.dwl.unifi.tx.manager.CTxRxFacade.processTxNormal(CTxRxFacade.java:681)
at com.dwl.unifi.tx.manager.CTxRxFacade.processTx(CTxRxFacade.java:544)
at com.dwl.base.requestHandler.DWLRequestHandler.processTransaction(DWLRequestHandler.java:1276)
at com.dwl.base.requestHandler.DWLRequestHandler.processTx(DWLRequestHandler.java:608)
at com.dwl.base.requestHandler.DWLServiceControllerBase.processRequest(DWLServiceControllerBase.java:253)
at com.dwl.base.requestHandler.beans.EJSLocal0SLDWLServiceController_2c54996d.processRequest(EJSLocal0SLDWLServiceController_2c54996d.java)
at com.dwl.base.requestHandler.beans.EJSProxy$$MDMServiceControllerLocal.processRequest(Unknown Source)
at com.dwl.jmsadapter.util.DWLCustomerApp.submit(DWLCustomerApp.java:149)
at com.ibm.mdm.jmsadapter.util.MessageProcessingManager.submitRequest(MessageProcessingManager.java:127)
at com.dwl.jmsadapter.mdb.MDBRequestReceiverBean.processMessage(MDBRequestReceiverBean.java:173)
at com.dwl.jmsadapter.mdb.MDBRequestReceiverBean.onMessage(MDBRequestReceiverBean.java:128)
at com.ibm.ejs.container.WASMessageEndpointHandler.invokeJMSMethod(WASMessageEndpointHandler.java:138)
at com.ibm.ws.ejbcontainer.mdb.MessageEndpointHandler.invokeMdbMethod(MessageEndpointHandler.java:1146)
at com.ibm.ws.ejbcontainer.mdb.MessageEndpointHandler.invoke(MessageEndpointHandler.java:844)
at com.sun.proxy.$Proxy82.onMessage(Unknown Source)
at com.ibm.mq.connector.inbound.MessageEndpointWrapper.onMessage(MessageEndpointWrapper.java:131)
at com.ibm.mq.jms.MQSession$FacadeMessageListener.onMessage(MQSession.java:133)
at com.ibm.msg.client.jms.internal.JmsSessionImpl.run(JmsSessionImpl.java:2913)
at com.ibm.mq.jms.MQSession.run(MQSession.java:958)
at com.ibm.mq.connector.inbound.ASFWorkImpl.doDelivery(ASFWorkImpl.java:111)
at com.ibm.mq.connector.inbound.AbstractWorkImpl.run(AbstractWorkImpl.java:238)
at com.ibm.ejs.j2c.work.WorkProxy$RunWork.run(WorkProxy.java:282)
at java.security.AccessController.doPrivileged(AccessController.java:666)
at javax.security.auth.Subject.doAs(Subject.java:490)
at com.ibm.websphere.security.auth.WSSubject.doAs(WSSubject.java:133)
at com.ibm.ejs.j2c.work.WorkProxy$RunWork.run(WorkProxy.java:285)
at com.ibm.ws.security.util.AccessController.doPrivileged(AccessController.java:63)
at com.ibm.ejs.j2c.work.WorkProxy.run(WorkProxy.java:667)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1892)
Tuesday, September 17, 2019
maxRetryLimit - Check for Retry
The MDM CONFIGELEMENT setting /IBM/MessagingAdapter/Exception/maxRetryLimit controls the number of retries:
/IBM/MessagingAdapter/Exception/maxRetryLimit
· Description: Determines how many times the Messaging Adapter attempts to reprocess a failed inbound request message by invoking DWLServiceController.
· Default value: 3
· Dynamic: true
·
If you want to see it in action, you will have to turn on INFO level logging for
com.dwl.jmsadapter.mdb.MDBRequestReceiverBean class
as the logging code is below
| | |
| | if(currentRetryCount <= getMaxRetryLimit(manager.getControl()) && manager.shouldRetry(e)) { |
| | if (logger.isInfoEnabled()) { |
| | logger.info(ResourceBundleHelper.resolve( |
| | ResourceBundleNames.MESSAGING_ADAPTER_STRINGS, |
| | INFO_DWLJMSMessageProcessor_MessageRetry, |
| | new Object[] {manager.getMessageId(), currentRetryCount})); |
| | } |
| | processMessage(manager, currentRetryCount); |
| | } |
There are no such settings for the retry interval setting in MDM. Updating the CONFIGELEMENT and using the retryErrorCodeList' seems like the only option within MDM. You can most likely do it programmatically outside of MDM, for example like in the earlier article I sent you, Identifying database deadlocks and retrying transactions. However, there is no other settings within MDM to control for the number of retries or a delay between retries.
_______________________________________________________________________
If you received this email in error, please advise the sender (by return email or otherwise) immediately. You have consented to receive the attached electronically at the above-noted email address; please retain a copy of this confirmation for future reference.
Si vous recevez ce courriel par erreur, veuillez en aviser l'expéditeur immédiatement, par retour de courriel ou par un autre moyen. Vous avez accepté de recevoir le(s) document(s) ci-joint(s) par voie électronique à l'adresse courriel indiquée ci-dessus; veuillez conserver une copie de cette confirmation pour les fins de reference future.