| Author |
Message
|
| latitude |
 Posted: Thu Aug 20, 2009 11:22 am Post subject: Concat and Split |
 |
|
Apprentice
Joined: 17 Aug 2009
Posts: 36
|
Hi All,
I have a requirement to concat two values and write to a single field but need the capability to slip them at a later stage on a different flow. I was thinking of using a special character to identify the split but there’s a risk of that special character appearing as part of any of the field values. Has anyone done something similar in the past?
Your views appreciated |
|
| Back to top |
|
 |
| francoisvdm |
| Posted: Thu Aug 20, 2009 9:03 pm Post subject: |
|
|
Partisan
Joined: 09 Aug 2001
Posts: 332
|
If you can "add" another field somewhere you can put in it the "length" of the first field... but yes, this is not very clean.
_________________
If you do not know the answer or you get the urge to answer with "RTFM" or "Search better in this forum", please refrain from doing so, just move on to the next question. Much appreciated.
Francois van der Merwe |
|
| Back to top |
|
|
| Luke |
| Posted: Fri Aug 21, 2009 12:22 am Post subject: |
|
|
Centurion
Joined: 10 Nov 2008
Posts: 128
Location: UK
|
Hi,
What kind of field(s) - which domain, fixed or variable length, format?
I'd guess from what you're saying that they can contain any character and be of variable length ... ?
If so, this sounds like a pretty dodgy requirement. Why do you need to do it? Maybe if we can understand the requirement a bit better, someone can offer some guidance.
Cheers |
|
| Back to top |
|
|
| latitude |
| Posted: Fri Aug 21, 2009 12:25 am Post subject: |
|
|
Apprentice
Joined: 17 Aug 2009
Posts: 36
|
Let me explain this little in detail. I have a consuming application and two web services. When the first web service is called, it passes some web service specific data that the second web service requires. Considering service orientation and loose coupling I do not want to save this web service specific data in the consuming application.
I’m willing to accommodate one field on the consuming application for this purpose. The requirement is to concat these web service specific data on the first web service response and save them in a single field on the consuming application. When the second web service call is made I want to split them on the second business service flow using some sort of machanism which will work with out any errors. ie. There is a risk of using a speacial character because there is a chance of that character aprearing on any of the data values.. |
|
| Back to top |
|
|
| latitude |
| Posted: Fri Aug 21, 2009 12:36 am Post subject: |
|
|
Apprentice
Joined: 17 Aug 2009
Posts: 36
|
| They are string Fields and length may vary. Domain is XMLNSC. |
|
| Back to top |
|
|
| Luke |
| Posted: Fri Aug 21, 2009 1:02 am Post subject: |
|
|
Centurion
Joined: 10 Nov 2008
Posts: 128
Location: UK
|
I don't really see the problem with the fact that some data returned from your first web service is then used when invoking a second web service. Although I'm not sure exactly what you mean by "web service specific data".
But why do you think it's a bad idea to use 2 fields, but 1 is OK? I don't get the distinction. Surely it's either valid to do it that way or it's not, regardless of whether it's 1 field or 20?
Use 2 fields, or re-design it would be my advice. |
|
| Back to top |
|
|
| latitude |
| Posted: Fri Aug 21, 2009 1:41 am Post subject: |
|
|
Apprentice
Joined: 17 Aug 2009
Posts: 36
|
What I meant by the web service specific data is that the first web service(third party company) passes some fields such as approval ID and transaction ID. These fields need to be saved because they are required by the second web service (of the same company) but the approval id or the transaction id are not required(business specific) data items for the consuming application. If two fields are created called approval ID and transaction id in the consuming application, they need be changed if decided to use different web services from a different company in the future.
If a single field is created on the consuming application called WebServiceData, It doesn’t matter how many or what data items (concated) are saved in this filed. Therefore this field doesn't need to be changed even if decided to go with a different web service(s) in the future. The only place where it has to change is in the middleware as it should be.
Hope I made it clear. |
|
| Back to top |
|
|
| Luke |
| Posted: Fri Aug 21, 2009 1:56 am Post subject: |
|
|
Centurion
Joined: 10 Nov 2008
Posts: 128
Location: UK
|
Could you use a CDATA section then? Call your CDATA section WebServiceData or whatever, then have whatever fields you like within it?
That way, your app is oblivious, but you can extract the CDATA and parse it ... |
|
| Back to top |
|
|
|
|
