| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| SWIFT Message set- Usage of Delimiter |
« View previous topic :: View next topic » |
| Author |
Message
|
| rinchu |
 Posted: Mon May 26, 2014 3:28 am Post subject: SWIFT Message set- Usage of Delimiter |
 |
|
Newbie
Joined: 13 Sep 2012
Posts: 7
|
Hi I have created a SWIFT MT940 message set to parse a File act message.
There are n number of MT940 message in a fileact message.One MT940 message is separated by different delimiters(@,; ..).
Can you please tell me how to handle the delimiter in such case within the message set.
Below is one of the sample message
| Code: |
{1:F01CABCALRSBXXX1707543114}{2:O9400619140215BKLMHI3NXICM00219042661402150119S}{3:{108:40215LYY45307CHI}}{4:
:20:1404699001011925
:25:010234798808
:28C:14045/2
:60M:C140319CLP570773900,
:61:1403190214CP336455,* please do not use *//6743633
/CTC/002/DOC DEPOSIT FORE LA
:86:/PT/DE/EI/258-OF. CIUDAD EMPRESARIAL OP.
:61:1403190214DP3232991,NTRFNONREF//100000091
/CTC/332/FUNDS TRANSFER TBA
:86:/PT/DE/EI/472-PACIFICO
:61:1403190214DP372668368,NTRFNONREF//100000105
/CTC/332/FUNDS TRANSFER TBA
,
:64:C140319CLP188081118,
:65:C140217CLP208670551,
:86:/PG/2L
-}{5:{CHK:1C0EA868209F}{MRF:140215061934140215CITIPRSJBXXX1707543114}}
--
{1:F01IBMXUS33AXXX0447571318}{2:O9402227120908DEUTUIJIIXXX49810306021209081627N}{3:{108: }}{4:
:20:240125830000
:25:6007909SDF9A0070/189100
:28C:00197/001
:60F:C131007EUR19211826,90
:61:120908C4625,98NTRFNONREF
:86: /BENM/IBM GERMANY GMBH
/ORDP/IBM GERMANY KREDITBANK
/REMI/1012367770890390070 UBERWEISUNG
PAYMENT AUGUST DIRECT COSTS BH 250410 0339 ADVICE TO K
ATARINA TREMBOVA 120908P3TX8818QM
EZU-REF. NOS1209080004807
:61:120908C8168,71NTRFDTA100800060010//03MT120908124927
/OCMT/EUR8168,71/
:86: /ORDP/IBM GERMANY GMBH
/REMI/UBERWEISUNG INL.ZAHL. 03MT120908124927
YOUR REF: DTA100800060010 BTR: EUR 8.168,71
ZGR: UEBERTRAG UEBERTRAG /OCMT/EUR8168,71/
/0820000000 BIC:GENODESGXXX
:61:120908C10415,19NTRFNONREF
:86: /BENM/IBM GERMANY GMBH
/ORDP/IBM GERMANY KREDITBANK
/REMI/1012367770890390070 UBERWEISUNG
PAYMENT AUGUST DIRECT COSTS BH 250410 1030 ADVICE TO K
ATARINA TREMBOVA 120908P3TX8818PO
EZU-REF. NOS1209080004802
:61:120908C12356,83NTRFNONREF
:86: /BENM/IBM GERMANY GMBH
/ORDP/IBM GERMANY KREDITBANK
/REMI/1012367770890390070 UBERWEISUNG
SEPTEMBER INTEREST FOR CASH DEPOSITS.
120908P3TX8818PT EZU-REF. NOS1209080004803
:62M:C120908EUR19247393,61
-}
;{1:F01PTSWBEB0AXXX0055006187}{2:O9401154070403LRLRXXXX4A0700005713680704031254N}{4:
:16R:GENL
::19A::SETT//USD900000000001,50
34
:19A::RESU//NUSD1,34
:92B::EXCH//USD/EUR/1,3456789012345
:16S:AMT
:16S:SETDET
:16R:OTHRPRTY
:95Q::EXCH//x
//x
:97A::SAFE//x
:16S:OTHRPRTY
-}{5:{CHK:BE1BA496CB07}{TNG:}};
{1:F01IBMXUS30AXXX0004000045}{2:O9421532081202MELNUS30AXXX47354878600812021532N}
{4:
:20:BNY Mellon Tst 8
:25:123456
:28C:1/1
:60F:C081015USD123,45
:62F:C081015USD123,45
:64:C081015USD123,45
-} |
Regards
Rinchu |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Mon May 26, 2014 9:31 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
You should perhaps be using V8 or IIB9 and DFDL instead of MRM and TDS? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| kimbert |
| Posted: Mon May 26, 2014 1:45 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
Some facts, then a comment.
The MRM parser does not allow multiple alternative delimiters to be specified for a single group/complex type.
The DFDL language does allow a 'separator' ( roughly the same as an MRM delimiter ) to be a space-separated list of alternatives.
It is possible, if you apply enough time and effort, to trick the MRM parser into accepting multiple alternative delimiters for a group / complex type.
But there's a great big question hanging over this thread, for me at least. What was the 'designer' of this file format smoking?! Is it a real-world file format, or some artificial example cooked up to demonstrate the strengths/weaknesses of a particular set of products?
_________________
Before you criticize someone, walk a mile in their shoes. That way you're a mile away, and you have their shoes too. |
|
| Back to top |
|
|
| rinchu |
| Posted: Mon May 26, 2014 11:08 pm Post subject: |
|
|
Newbie
Joined: 13 Sep 2012
Posts: 7
|
Thanks for the reply.
I must say this was one sample message was which I could paste here.The other sample messages are all worst than this.Having an awkward time dealing with it.
As I have no choice.Had proposed to use space delimiter between MT940 messages, still am not able to parse the message.When I use @ delimiter it works fine as this symbol seems to be unique within the message.
Can you suggest how i can handle space delimiter.
Regards
Rinchu |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue May 27, 2014 5:56 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| Had proposed to use space delimiter between MT940 messages, still am not able to parse the message.When I use @ delimiter it works fine as this symbol seems to be unique within the message. |
and...
| Quote: |
| Can you suggest how i can handle space delimiter |
My advice is to stop guessing, and start thinking. If @ works, then why not use @ ( if you are 100% sure that it will never occur within one of the MQ940 messages ).
Alternatively, why not choose a byte value that cannot ever occur in an MT940 message.
_________________
Before you criticize someone, walk a mile in their shoes. That way you're a mile away, and you have their shoes too. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue May 27, 2014 6:39 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| In theory, one could pretend it's not a delimiter, and treat it as another field, perhaps optional, that's a single character long. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue May 27, 2014 6:57 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
I guess a record delimiter option of "Parsed Record Sequence" would work in the File Input Node?
If not then set the record delimiter to your chosen character, then remove it in a compute node before the message is parsed later in the flow.
If you have a working MT940 message set, I don't see a need to change it, if it's easier to just remove the delimiter.
@kimbert - this is real world - MT940 is one of the Swift FIN formats. It's a nightmare to model these which is why IBM charge for a message set to do it!
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue May 27, 2014 2:31 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
@zpat : agreed - I know the SWIFT standard very well. But this is not about how to model MT940. It's about the best strategy for delimiting a stream of MT940 messages.
In my experience 'trying' @ or any other character is not a good strategy. 'Trying' is only a safe strategy when your test data is close to perfect. Carefully and deliberately selecting a good delimiter seems like a better strategy to me.
_________________
Before you criticize someone, walk a mile in their shoes. That way you're a mile away, and you have their shoes too. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
