How consumer is determined

Question

Hi Experts:
I have 2 B2B systems (systemA and systemB) setup, where I send a 4C1 (Inventory Report) from SystemA to SystemB using ResettaNet protocol. To systemB, it is an inbound 4C1 message.
In SystemB, I have configure 4C1 operational capability for a trading parnter and set "*Document Routing ID = b2b4c1user*". Also, I have successfully deployed 4C1 configuration in systemB. I also confirmed Consumer is "b2b4c1user" by viewing WSDL file in IE browser for SystemB 4C1 configuration.
- <binding name="Dequeue_binding" type="tns:Dequeue_ptt">
<pc:inbound_binding />
- <operation name="Dequeue_Pip4C1InventoryReportNotification_RosettaNet-V02.00">
<jca:operation ActivationSpec="oracle.tip.adapter.aq.inbound.AQDequeueActivationSpec" QueueName="*IP_IN_QUEUE*" DatabaseSchema="B2B" ObjectFieldName="PAYLOAD" Consumer="*b2b4c1user"* OpaqueSchema="false" PayloadHeaderRequired="true" />
- <input>
<jca:header message="tns:Header_msg" part="Header" />
</input>
</operation>
</binding>
Then, I sent several 4C1 messages from systemA to systemB (confirmed by run Wire Message report in both systems) sucessfully.
However, when I run following query in SystemB:
SELECT
queue,
msg_id,
msg_state,
enq_user_id,
consumer_name
FROM
b2b.AQ$IP_QTAB;
The result is as followings:
Queue_______ MSG_ID___________________________Msg_State________Enq_user_ID____Consumer_name
IP_IN_QUEUE__693EE85F0C1136AFE0440003BA0C8850__READY__________B2B____________B2BUSER
IP_IN_QUEUE__693F16FFC1E838E3E0440003BA0C8850__READY__________B2B____________B2BUSER
As you can see consumer_name from my query is 'B2BUSER', which doesn't match to 4C1 configuration deployment value "b2b4c1user" in SystemB)
Here is my question:
- How value of "Consumer_name" in this query is determined? Why it doesn't match to 4C1 configuration deployment value "b2b4c1user".
- How to fix this so that vvalue of Consumer_name returned from above view = 'b2b4c1user"? <== this is most important question I hope someone can answer.
Basically, in SystemB (which will recieve multiple different inbound messages from SystemA using Resettanet. All those messages will be arrived in IP_IN_QUEUE), we want use different consumer name for each different type of inbound message exchanged over Rosettanet with a remote trading partner. For example:
Document Type Consumer
=======================
3C7 (Self-Billing Invoice) b2b3c7user
4C1(Inventory Report) b2b4c1user
Thanks!
Kevin
Edited by: kzhangkzhang on May 15, 2009 12:26 PM
Edited by: kzhangkzhang on May 15, 2009 12:27 PM
Edited by: kzhangkzhang on May 15, 2009 12:27 PM
Edited by: kzhangkzhang on May 15, 2009 12:27 PM

Answer 1

Hi All:
To continue figuring out my issue, I have tried same trick (recreating same document definition object) several times. The I execute the following custom SQL I wrote to see the "Document Routing ID" parameter for my 4C1 V02.03 document type objects.
SELECT
dt.NAME                              doc_type,
dt.revision                         rev,
dt.ID                              doc_type_id,
dd.NAME                              doc_definition,
dd.ID                              doc_def_id,
     pt.ID                              param_id,
     pt.NAME                              param_name,
pt.displayname                    param_display,
     dtp.stringvalue                    param_value,
dtp.ID                              param_value_id,
ddu.ID                              doc_def_usage_id
FROM     
     b2b.tip_parameter_t                         pt,
     b2b.tip_documenttypeparameterval_t      dtp,
     b2b.tip_documentdefinitionusage_t     ddu,
     b2b.tip_documentdefinition_t          dd,
     b2b.tip_documenttype_t                    dt
WHERE
     1 = 1
AND dt.NAME = 'Pip4C1InventoryReportNotification'
AND dt.revision = 'V02.03'
AND dt.ID = dd.documenttype
AND dd.NAME = 'Pip4C1InventoryReport'
AND dd.ID = ddu.documentdefinition
AND ddu.ID = dtp.documentdefinitionusage
AND dtp.documenttypeparameter = pt.ID;
This query has return multiple rows:
Parameter
Doc Type Revision Doc Definition Parameter Value
Pip4C1InventoryReportNotificat V02.03 Pip4C1InventoryReportNoti Document Routing ID b2b4c1user
Pip4C1InventoryReportNotificat V02.03 Pip4C1InventoryReportNoti DTD/XSD Namespace Convers BOTH
Pip4C1InventoryReportNotificat V02.03 Pip4C1InventoryReport DTD/XSD Namespace Convers BOTH
Pip4C1InventoryReportNotificat V02.03 Pip4C1InventoryReport Document Routing ID b2b4c1user
Pip4C1InventoryReportNotificat V02.03 Pip4C1InventoryReport DTD/XSD Namespace Convers BOTH
Pip4C1InventoryReportNotificat V02.03 Pip4C1InventoryReport Document Routing ID b2b4c1user
Pip4C1InventoryReportNotificat V02.03 Pip4C1InventoryReport DTD/XSD Namespace Convers BOTH
Pip4C1InventoryReportNotificat V02.03 Pip4C1InventoryReport Document Routing ID b2b4c1user
Pip4C1InventoryReportNotificat V02.03 Pip4C1InventoryReport DTD/XSD Namespace Convers BOTH
Pip4C1InventoryReportNotificat V02.03 Pip4C1InventoryReport Document Routing ID b2b4c1user
Pip4C1InventoryReportNotificat V02.03 Pip4C1InventoryReport DTD/XSD Namespace Convers BOTH
Pip4C1InventoryReportNotificat V02.03 Pip4C1InventoryReport Document Routing ID b2b4c1user
Pip4C1InventoryReportNotificat V02.03 Pip4C1InventoryReport DTD/XSD Namespace Convers BOTH
Pip4C1InventoryReportNotificat V02.03 Pip4C1InventoryReport Document Routing ID b2b4c1user
Pip4C1InventoryReportNotificat V02.03 Pip4C1InventoryReport DTD/XSD Namespace Convers BOTH
Pip4C1InventoryReportNotificat V02.03 Pip4C1InventoryReport Document Routing ID b2b4c1user
Pip4C1InventoryReportNotificat V02.03 Pip4C1InventoryReport DTD/XSD Namespace Convers BOTH
Pip4C1InventoryReportNotificat V02.03 Pip4C1InventoryReport Document Routing ID b2b4c1user
Pip4C1InventoryReportNotificat V02.03 Pip4C1InventoryReport DTD/XSD Namespace Convers BOTH
Pip4C1InventoryReportNotificat V02.03 Pip4C1InventoryReport DTD/XSD Namespace Convers BOTH
Pip4C1InventoryReportNotificat V02.03 Pip4C1InventoryReport Document Routing ID b2b4c1user
Pip4C1InventoryReportNotificat V02.03 Pip4C1InventoryReport Document Routing ID b2b4c1user
Pip4C1InventoryReportNotificat V02.03 Pip4C1InventoryReport DTD/XSD Namespace Convers BOTH
Pip4C1InventoryReportNotificat V02.03 Pip4C1InventoryReport Document Routing ID b2b4c1user
24 rows selected.
The count will increase by 2 each time after I recreate same 4C1 V02.03 document type object.
Here is my theory to explain why B2B didn’t set value to “b2b4c1user” for consumer column when it drops inbound 4C1 message.
I have tried this trick many times to update “Document Routing ID” for my 4C1 V02.03. The trick is to re-create 4C1 V02.03 document definition again and uncheck box "Use default Document definition" and enter value "b2b4c1user" for "Document Routing ID" parameter. Because I tried this many times, there are many “Document Routing ID” parameter for my 4C1 document definition. I confirmed this by executing a custom SQL I wrote myself.
If Java/PLSQL code used by B2B to determine value of consumer assumes only one “Document Routing ID” parameter can exist, it could throw an exception when it found too many rows. Once exception happens, it will use default value “b2buser” for consumer value.
This is just my theory and no way I can verify it. I am guessing if I can come up with a datafix to get rid of extra “Document Routing ID” for 4C1 and just leave one “Document Routing ID” in the system, then it might work again.
Not sure anyone can help me about this issue.
Any suggestion?
Thanks!
Kevin
Edited by: kzhangkzhang on May 20, 2009 7:11 AM