Author |
Message
|
latitude |
Posted: Wed Aug 19, 2009 1:18 am Post subject: Unique Transaction Number |
|
|
 Apprentice
Joined: 17 Aug 2009 Posts: 36
|
I have a solution for a problem but not sure if it is the most appropriate way of achieving it. I would like to see if there is a another way to achieve this. So here it is;
There is a web Service which requires a unique transaction number but the consuming applications will not provide one. So it is left to the WMB to generate a unique number and insert it to the outgoing message. The following options were considered;
1. Create a counter and store the transaction number in a DB but unfortunately this option is not possible due to licensing issue.
2. Create a counter and keep the value in the memory but the value will be lost if the broker, execution group or the flow is restarted
3. Solution found is to create a different broker flow which will generate unique transaction numbers and put them to a MQ Queue and the main flow will read this queue to get a transaction number.
Your views are appreciated. |
|
Back to top |
|
 |
Luke |
Posted: Wed Aug 19, 2009 1:54 am Post subject: |
|
|
Centurion
Joined: 10 Nov 2008 Posts: 128 Location: UK
|
Does it have to be numeric? Broker can provide you with unique identifiers, but they have letters in too. See UUIDASCHAR function ... |
|
Back to top |
|
 |
somsayan |
Posted: Wed Aug 19, 2009 2:00 am Post subject: |
|
|
Apprentice
Joined: 06 Apr 2007 Posts: 49
|
If you indeed need an integer value can't you obtain it from the CURRENT_TIMESTAMP. From it if you get the macro-second value you can eliminate all the '-' to get the unique value |
|
Back to top |
|
 |
latitude |
Posted: Wed Aug 19, 2009 2:27 am Post subject: |
|
|
 Apprentice
Joined: 17 Aug 2009 Posts: 36
|
Many thanks for the prompt replies guys.
It doesn’t have to be a numeric but only concern is the length of the value should be 5
Again with the timestamp the problem is the length.
Sorry I forgot to mention that from the beginning |
|
Back to top |
|
 |
Luke |
Posted: Wed Aug 19, 2009 2:34 am Post subject: |
|
|
Centurion
Joined: 10 Nov 2008 Posts: 128 Location: UK
|
5 characters? I don't think it's likely to be all that unique then is it?
How do your requirements define 'unique'? |
|
Back to top |
|
 |
latitude |
Posted: Wed Aug 19, 2009 2:46 am Post subject: |
|
|
 Apprentice
Joined: 17 Aug 2009 Posts: 36
|
This has to be unique for that day and also between consumers.
Actual field size is 6 and im keeping the first letter as a system identifier ie. A for SystemA , B for SystemB and rest of the 5 letters needs to be unique for the day assuming the WMB process over 50000 messages per day. |
|
Back to top |
|
 |
fjb_saper |
Posted: Wed Aug 19, 2009 4:32 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Bad design. Unique numbers usually go by 36 to 48 and more chars depending on the system generating it. You could also use the MQ msgid but this is a byte array of 24 bytes... or hex representation 48 chars....
If you absolutely need to stick by your numbers you should use the DB's sequence generator... but again this is not likely to be unique per day but unique over the lifetime of the table.... and very likely to bust your length requirements... so I would suggest you look at a new design.
Have fun  _________________ MQ & Broker admin |
|
Back to top |
|
 |
latitude |
Posted: Wed Aug 19, 2009 5:58 am Post subject: |
|
|
 Apprentice
Joined: 17 Aug 2009 Posts: 36
|
Changing the design is not an option. We are consuming a third party Web Service and it is one of their requirement.  |
|
Back to top |
|
 |
Vitor |
Posted: Wed Aug 19, 2009 6:02 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
latitude wrote: |
Changing the design is not an option. We are consuming a third party Web Service and it is one of their requirement.  |
So this design doesn't allow for more than 100,000 transactions a day?
The solution you've come up with requires this additional queue to be maintained (populated or cleared as required), another flow to be run (or not) and assumes the queue isn't cleared accidently. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
latitude |
Posted: Wed Aug 19, 2009 6:17 am Post subject: |
|
|
 Apprentice
Joined: 17 Aug 2009 Posts: 36
|
This field is not a numeric and possible to have alphanumeric values, therefore you could have more than 100000 unique numbers. |
|
Back to top |
|
 |
Vitor |
Posted: Wed Aug 19, 2009 6:21 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
latitude wrote: |
This field is not a numeric and possible to have alphanumeric values, therefore you could have more than 100000 unique numbers. |
Good point - missed that.
I'd still ask why they decided not to use something a bit more standard for a unique id.
My other comments apply. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
Bartez75 |
Posted: Fri Aug 21, 2009 6:25 am Post subject: |
|
|
 Voyager
Joined: 26 Oct 2006 Posts: 80 Location: Poland, Wroclaw
|
Hi latitude
Quote: |
1. Create a counter and store the transaction number in a DB but unfortunately this option is not possible due to licensing issue.
|
Could you please tell me shortly what license issue you have in your solution number 1?
Just wondering, maybe I will have the same some day... |
|
Back to top |
|
 |
WMBDEV1 |
Posted: Sat Aug 22, 2009 1:14 pm Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009 Posts: 888 Location: UK
|
Bartez75 wrote: |
Could you please tell me shortly what license issue you have in your solution number 1?
|
I'm guessing hes referring to the restrictions imposed on using the DB used by the broker for storing custom tables. From memory, if you're using DB2 to host the broker tables and you then add your own tables into it you then have to pay for a full DB2 license.
I think this used to be (and still is) the case but if not im happy for a passing IBMer to correct me. |
|
Back to top |
|
 |
latitude |
Posted: Mon Aug 24, 2009 9:08 am Post subject: |
|
|
 Apprentice
Joined: 17 Aug 2009 Posts: 36
|
Yes, I was refering to keeping the application data on a DB2 database. |
|
Back to top |
|
 |
jbanoop |
Posted: Mon Aug 24, 2009 12:42 pm Post subject: |
|
|
Chevalier
Joined: 17 Sep 2005 Posts: 401 Location: SC
|
Just trying to understand option #3, the message in the queue would always contain the latest transaction # is it ? And every time you consume, you create a new message with the incremented value of the counter and place it on the queue again ? |
|
Back to top |
|
 |
|