SOA Messages Are Failing With TimeStamp Validation Error (Doc ID 2681981.1)

Last updated on MAY 21, 2024

Applies to:

Goal

1. CUSTOMER have 2 versions of BillCycleResponse and request (ex: please see below). According integration document V2 version supported by MDM 2.2 SP2/SP3 but will be deprecteated with MDM 2.3.0.0
   They want to know if we V1 (the 2nd queue/composite below) is supported with MDM 2.2 SP2/SP3.
   
   Queue:
   OUMDM2BillCycleSyncResponseV2
   OUMDM2BillCycleSyncResponse
   Composites:
   OUMDM2BillCycleSyncResponseV2EBF
   OUMDM2BillCycleSyncResponseEBF
2. The default policy for CCB2-MDM2 productized integration is oracle/wss_http_token_client_policy which is specified in InstallProperties.xml.But this polciy is not including "TimeStamp" header which is the reason why the messages are failing. So we updated the deefault policy of BPEL process of "OUMDM2OUCCB2BillCycleSyncResp" composite from oracle/wss_http_token_client_policy to oracle/wss_http_token_over_ssl_client_policy
   
   This new policy by default includes "timestamp" and it worked for us.
   
   Can you confirm if the change of policy for this  composite is supported by Oracle ?
   Can you also confirm if it is supported  if we change that default policy (oracle/wss_http_token_client_policy) to oracle/wss_http_token_over_ssl_client_policy for all the composites/components in CCB2-MDM2 integration?
3. Customer redeployed integration by updating with InstallProperties.xml file with the following policies but i still do not see any composites attached to this one.
   
   <policy>oracle/wss_http_token_over_ssl_client_policy</policy>
4. can you confirm what this properly is not being parsed to a value? ${SOA.JMS.AdapterReceiveThreads}
   where can we set the value for that instead of going trough each composite and manually updating the value.
5. when customer reinstall the composite and to point the context to /ouaf/webservices for both CCB and MDM, we noticed that there are still occurrences/call to XAIXApp. Also, it seems the error handling is not working properly.
   ERROR: parm1="XSD_TO_OUAF" parm2="Invalid format: &amp;quot;2019-12-30-23.59.59&amp;quot; is malformed at &amp;quot;-23.59.59&amp;quot;" text="Date/Time conversion XSD_TO_OUAF error: Invalid format: &amp;quot;2019-12-30-23.59.59&amp;quot; is malformed at &amp;quot;-23.59.59&amp;quot;"/>&lt;ServerMessage>&lt;Category>11001&lt;/Category>&lt;Number>4618&lt;/Number>&lt;CallSequence/>&lt;ProgramName>DateTimeConverterService&lt;/ProgramName>&lt;Text>Date/Time conversion XSD_TO_OUAF error: Invalid format: "2019-12-30-23.59.59" is malformed at "-23.59.59"&lt;/Text>&lt;Description> &lt;/Description>&lt;Table/>&lt;Field/>&lt;/ServerMessage>&lt;/ouaf:Fault>}
   cause: {Client received SOAP Fault from server : Client error}
   […]
   [2020-02-03T04:03:05.310-05:00] [soa_server2] [ERROR] [] [oracle.soa.bpel.engine] [tid: DaemonWorkThread: '28' of WorkManager: 'default_Adapters'] [userId: <anonymous>] [ecid: a3e890f1-09ab-47e3-a242-890ba5ab1231-0029e28b,0:1] [APP: soa-infra] [partition-name: DOMAIN] [tenant-name: GLOBAL] [oracle.soa.tracking.FlowId: 300274] [oracle.soa.tracking.InstanceId: 304790] [oracle.soa.tracking.SCAEntityId: 90510] [oracle.soa.tracking.FaultId: 191486] [composite_name: OUCCB2OUMDM2OnlineBDReqJMSReadSvc!1.0] [FlowId: 0000N0AIVW07u1b5lJ_AiZ1UCi6100004I] Not fatal connection error ... not retrying: class com.collaxa.cube.engine.EngineException: Fault not handled.[[
   failure to handle a fault thrown from a scope, by any blocks in the scope chain.
   This exception occurred because the fault thrown in the BPEL flow was not handled by any fault handlers and reached the top-level scope.
   A top-level fault handler should be added to the flow to handle faults not caught from within the flow.
6. Customer encountering the issue after we deployed the fix. basically, the billing part, the bill stuck in awaiting acknowledgement. here is the description:
   
   • CCB sent the request date of 02-10-2020 12AM
   • SOA tagged the dates with EST time zone
   • MDM received the dates, now converted to CST, which is 02-09-2020 11PM CST
   • In MDM, there is a base algorithm that will convert time zone based on the source, CCB is EST.
   • From 02-09-2020 11PM, MDM applied another conversion from EST to CST. Resulting for a 02-09-2020 10PM CST
   • As a result, billing processes the transaction as:
   o 02-09-2020 10PM CST = 02-09-2020 11PM EST

Solution

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.