| Author |
Message
|
| catshout |
 Posted: Mon Nov 10, 2014 2:05 am Post subject: Setting Reset Content Descriptor properties dynamically |
 |
|
Acolyte
Joined: 15 May 2012
Posts: 57
|
I've built a flow that contains a Reset Content Descriptor node re-setting the message domain to DFDL and the message to a message defined in a DFDL schema.
1. Is it possible to change the RCD node properties dynamically (e.g. in an ESQL node before the RCD node) within the LocalEnvironment during flow runtime? Otherwise, could RCD node functionality be done by ESQL coding?
2. Is it possible to access the message name value of a DFDL schema programatically in ESQL?
Thanks in advance for any hints. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Nov 10, 2014 5:22 am Post subject: Re: Setting Reset Content Descriptor properties dynamically |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| catshout wrote: |
| I've built a flow that contains a Reset Content Descriptor node re-setting the message domain to DFDL and the message to a message defined in a DFDL schema. |
Why?
| catshout wrote: |
| 1. Is it possible to change the RCD node properties dynamically (e.g. in an ESQL node before the RCD node) within the LocalEnvironment during flow runtime? |
No
| catshout wrote: |
| Otherwise, could RCD node functionality be done by ESQL coding? |
Yes.
| catshout wrote: |
| 2. Is it possible to access the message name value of a DFDL schema programatically in ESQL? |
Why?
It's possible to obtain the name used to create the message tree you're looking at. It's not possible to obtain a list of all possible schemas and then use them.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| catshout |
| Posted: Mon Nov 10, 2014 5:55 am Post subject: |
|
|
Acolyte
Joined: 15 May 2012
Posts: 57
|
| Quote: |
| Quote: |
catshout wrote:
I've built a flow that contains a Reset Content Descriptor node re-setting the message domain to DFDL and the message to a message defined in a DFDL schema. |
Why? |
I'm getting a HTTP Response from host as a BLOB. After deleting the HTTP Header I'm going to validate the Response against a DFDL and build the message tree following the DFDL message structure. I'll check whether this could be done in the HTTP Request node itself.
| Quote: |
| Quote: |
catshout wrote:
2. Is it possible to access the message name value of a DFDL schema programatically in ESQL? |
Why?
It's possible to obtain the name used to create the message tree you're looking at. It's not possible to obtain a list of all possible schemas and then use them. |
I know the name of the appropriate DFDL schema (.xsd) and would like to use the message definition in there to validate against it. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Nov 10, 2014 6:03 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| catshout wrote: |
| I'm getting a HTTP Response from host as a BLOB. After deleting the HTTP Header I'm going to validate the Response against a DFDL and build the message tree following the DFDL message structure. I'll check whether this could be done in the HTTP Request node itself. |
It can.
| catshout wrote: |
| I know the name of the appropriate DFDL schema (.xsd) and would like to use the message definition in there to validate against it. |
That doesn't require an RCD (assuming for now the HTTPRequest node can't or won't do anything with the BLOB) to be set dynamically.
Unless the XSD varies in which case the question becomes how do you know the XSD to use in any given circumstance.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| catshout |
| Posted: Mon Nov 10, 2014 10:17 am Post subject: |
|
|
Acolyte
Joined: 15 May 2012
Posts: 57
|
Thanks Vitor for reply. Let me give a bit more background ..
The use case is a Web Service with appr. 20 Service Operations. Every one follows the scheme
SOAP Request -> (XML) Map SOAP Request to CopyBook (DFDL) -> Host HTTP Request (BLOB) -> RCD -> (DFDL) Map CopyBook to SOAPResponse (XML) -> SOAP Response
I'm going to set the map names dynamically based on the Service Operation. This works. The challenge is the cast from BLOB to the matching DFDL prior to the 2nd map. Currently there's being used a RCD node for, configured with the Message in a DFDL schema (statically for testing). I want to do the cast dynamically. The DFDL schema name is the same as the Service Operation, therefore I know the schema. The Message in there comes from a CopyBook import and I don't want to change this. So far the idea is to pick up the schema, read the Message name in there and use it for the cast.
May be I'm thinking to complicated and there's another, more elegant way. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Nov 10, 2014 10:30 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You don't need either of those two RCDs.
The 1st map will create an output tree in DFDL. The HTTP Request node will serialize that tree into a string.
The HTTPRequest node will receive a serialized DFDL message, and based on the properties you give it, will parse it as DFDL.
Or at a minimum, the map will. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Nov 10, 2014 10:33 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| catshout wrote: |
The use case is a Web Service with appr. 20 Service Operations. Every one follows the scheme
SOAP Request -> (XML) Map SOAP Request to CopyBook (DFDL) -> Host HTTP Request (BLOB) -> RCD -> (DFDL) Map CopyBook to SOAPResponse (XML) -> SOAP Response |
What converts the DFDL output into a BLOB? Why is the HTTPRequest node not tasked with serializing the DFDL?
| catshout wrote: |
| I want to do the cast dynamically. The DFDL schema name is the same as the Service Operation, therefore I know the schema. The Message in there comes from a CopyBook import and I don't want to change this. So far the idea is to pick up the schema, read the Message name in there and use it for the cast. |
You're going to have to code for this. You can't use an RCD like this.
| catshout wrote: |
| May be I'm thinking to complicated and there's another, more elegant way. |
If this is your requirement and this is the last bit that doesn't work, it's a bit late to re-engineer for elegance.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| magvlvri |
| Posted: Mon Nov 10, 2014 11:48 am Post subject: |
|
|
Apprentice
Joined: 07 Nov 2014
Posts: 26
|
Ok, i think he is trying to make this msgflow to be used for multiple message types where he might not know what kind of message type is returned in the HTTP Call response that is made in the middle of the message flow.
Its pretty simple, right after getting the initial request into the message flow, one can either store the message type in Environment variable or however one can find out the message type looking at the resposne from the HTTP call.
When you know the message type, you could just use PARSE statement to do the same thing that RCD node does. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Nov 10, 2014 11:57 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| magvlvri wrote: |
| Ok, i think he is trying to make this msgflow to be used for multiple message types where he might not know what kind of message type is returned in the HTTP Call response that is made in the middle of the message flow. |
What I was wondering (and what my most worthy associate is alluding to) is that the HTTPRequest node may be able to set the properties of the response such that the map associate & parse (or allow to be parsed). Now I'm not aware of that for an HTTP rather than a SOAP, but he does know more than me in the v9 arena.
I certainly agree with your interpretation of what the OP has as a use case.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| catshout |
| Posted: Mon Nov 10, 2014 1:06 pm Post subject: |
|
|
Acolyte
Joined: 15 May 2012
Posts: 57
|
| Quote: |
| Ok, i think he is trying to make this msgflow to be used for multiple message types where he might not know what kind of message type is returned in the HTTP Call response that is made in the middle of the message flow. |
Multiple messages (Service Operations) - yes. The HTTP response is currently being returned as a BLOB. I know the structure of the message content as can be derived from the Service Operation (name).
| Quote: |
| What converts the DFDL output into a BLOB? Why is the HTTPRequest node not tasked with serializing the DFDL? |
Of course the HTTP node can perform this task but therefore I need to know the Message definition name too. But I know the DFDL schema name only (same as Service Operation name). The Message definition name in there isn't known as the name is a different one as the schema name.
Question: Can the map node handle a BLOB input (HTTP response) and convert it into a DFDL structure before executing the map? The map name is the same as the Service Operation name and the Message structure is definend within the map.
| Quote: |
| If this is your requirement and this is the last bit that doesn't work, it's a bit late to re-engineer for elegance. |
Not really as I'm in a early design phase of the flow and being open for suggestions. No problem at all to re-design the whole thing. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Nov 10, 2014 1:40 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| catshout wrote: |
| But I know the DFDL schema name only (same as Service Operation name). The Message definition name in there isn't known as the name is a different one as the schema name. |
How (even using an RCD) are you going to describe the BLOB to IIB without the message name?
How does your current hard coded RCD do this without a message name?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| catshout |
| Posted: Mon Nov 10, 2014 2:07 pm Post subject: |
|
|
Acolyte
Joined: 15 May 2012
Posts: 57
|
| Quote: |
How (even using an RCD) are you going to describe the BLOB to IIB without the message name?
How does your current hard coded RCD do this without a message name? |
Currently it's hard coded in RCD. Making the flow generic I'm gonna to determine it from schema name (known) dynamically. That's my challenge. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Nov 10, 2014 2:11 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| You already know which one to use, from the operation name. |
|
| Back to top |
|
|
| kimbert |
| Posted: Mon Nov 10, 2014 3:15 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
catshout said:
| Quote: |
Of course the HTTP node can perform this task but therefore I need to know the Message definition name too. But I know the DFDL schema name only (same as Service Operation name). The Message definition name in there isn't known as the name is a different one as the schema name.
|
I think you may be making a mistake in your understanding of how IIB processes DFDL models. The xsd filename is *never* used by the IIB runtime. All DFDL xsds are loaded into a single 'model' that is associated with the IIB Application. You can parse or write a message using any of the *global* element declarations in any of those xsds.
Since you are writing ( serializing ) a message, the name of the global element will be taken from the first child of OutputRoot.DFDL. So your task is to ensure that when the message hits the output node, the name and namespace of OutputRoot.DFDL.*[1] exactly matches a global element declaration that has been deployed in one of the xsds.
_________________
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 |
|
|
| catshout |
| Posted: Mon Nov 10, 2014 11:23 pm Post subject: |
|
|
Acolyte
Joined: 15 May 2012
Posts: 57
|
Thanks kimbert. Got it.
| Quote: |
I think you may be making a mistake in your understanding of how IIB processes DFDL models. The xsd filename is *never* used by the IIB runtime. All DFDL xsds are loaded into a single 'model' that is associated with the IIB Application. You can parse or write a message using any of the *global* element declarations in any of those xsds.
So your task is to ensure that when the message hits the output node, the name and namespace of OutputRoot.DFDL.*[1] exactly matches a global element declaration that has been deployed in one of the xsds. |
Means as it is not possible to access the schema xsd name at runtime I need to know the appropriate global element name in the model. Either renaming the global element or holding a configuration (shared variable or UDP) that references a Service Operation name to the matching global element name. |
|
| Back to top |
|
|
|
|
