Imported from previous forum
I am working on validation rules. The validation is processed down stream against the parameters not the controls. I have run into a situation where I need a suggestion.
We have a set of controls as shown. If “Is Short?” is Yes, then the Locate ID is required. The “Is Short?” value is not associated with a parameter but the Locate ID is. So at the time of validation I don’t know if they they chose Yes so I can validate the locate id.
Is Short? o Yes o No Locate ID: [________]
Any suggestions?
I am working on validation rules. The validation is processed down stream against the parameters not the controls. I have run into a situation where I need a suggestion.
We have a set of controls as shown. If “Is Short?” is Yes, then the Locate ID is required. The “Is Short?” value is not associated with a parameter but the Locate ID is. So at the time of validation I don’t know if they they chose Yes so I can validate the locate id.
Is Short? o Yes o No Locate ID: [________]Any suggestions?
I am assuming this is a question related to FIXatdl. You could check the FIX Side field = ‘5’ (“Sell Short”). This assumes that the OMS is feeding/exposing key fields from the FIX order to the FIXatdl rendering component.
For instance:
<val:Edit field=“FIX_Side” operator=“EQ” value=“5” />
I think this might conflict with the spec. I am looking at the spec table on page 18. Seems like you would be unable to determine if the fixTag attributes are provided or not. Currently my code cycles through all parameters checking for fixTags. If one or more parameters are missing fixTags and the tag957Support is not true, I complain…
Then on page 31 describing Parameter/@fixTag:
Required when: parameter value is intended to be transported over the wire.
If fixTag is not provided then the Strategies-level attribute, tag957Support, must be set to true, indicating that the order recipient expects to receive algo parameters in the StrategyParameterGrp repeating group beginning at tag 957.
So, if they provided no fixTags with tag957Support set to true, the “temp” parameter would be sent…
One common approach is for the control that doesn’t currently have a parameter, associate it with a ‘dummy’ parameter, but omit the fixTag attribute. That way the control can participate in StrategyEdit validation without being sent on the FIX wire.
I am working on validation rules. The validation is processed down stream against the parameters not the controls. I have run into a situation where I need a suggestion.
We have a set of controls as shown. If “Is Short?” is Yes, then the Locate ID is required. The “Is Short?” value is not associated with a parameter but the Locate ID is. So at the time of validation I don’t know if they they chose Yes so I can validate the locate id.
Is Short? o Yes o No Locate ID: [________]Any suggestions?
I am assuming this is a question related to FIXatdl. You could check the FIX Side field = ‘5’ (“Sell Short”). This assumes that the OMS is feeding/exposing key fields from the FIX order to the FIXatdl rendering component.
For instance:
<val:Edit field=“FIX_Side” operator=“EQ” value=“5” />
To accomplish this when processing the FIXatdl and sending my orders I could:
- check to see if one or more parameters have a fixtag then send all the have a fixTag ignoring those that don’t.
- if none of the parameters have fixTags require tag957Support=true otherwise complain.
Do you see any problems with this?
Indeed, but personally I think the spec is being too prescriptive - I have seen more than one implementation that allows the fixTag attribute to be omitted without expecting tag957Support to be set. I’d be interested to hear what others thing…
I think this might conflict with the spec. I am looking at the spec table on page 18. Seems like you would be unable to determine if the fixTag attributes are provided or not. Currently my code cycles through all parameters checking for fixTags. If one or more parameters are missing fixTags and the tag957Support is not true, I complain…
Then on page 31 describing Parameter/@fixTag:
Required when: parameter value is intended to be transported over the wire.
If fixTag is not provided then the Strategies-level attribute, tag957Support, must be set to true, indicating that the order recipient expects to receive algo parameters in the StrategyParameterGrp repeating group beginning at tag 957.So, if they provided no fixTags with tag957Support set to true, the “temp” parameter would be sent…
One common approach is for the control that doesn’t currently have a parameter, associate it with a ‘dummy’ parameter, but omit the fixTag attribute. That way the control can participate in StrategyEdit validation without being sent on the FIX wire.
I am working on validation rules. The validation is processed down stream against the parameters not the controls. I have run into a situation where I need a suggestion.
We have a set of controls as shown. If “Is Short?” is Yes, then the Locate ID is required. The “Is Short?” value is not associated with a parameter but the Locate ID is. So at the time of validation I don’t know if they they chose Yes so I can validate the locate id.
Is Short? o Yes o No Locate ID: [________]Any suggestions?
I am assuming this is a question related to FIXatdl. You could check the FIX Side field = ‘5’ (“Sell Short”). This assumes that the OMS is feeding/exposing key fields from the FIX order to the FIXatdl rendering component.
For instance:
<val:Edit field=“FIX_Side” operator=“EQ” value=“5” />
Cathy, I think you misunderstood my suggestion. I was referring to the ability, within FIXatdl, to reference key fields from the New Order Single message which are NOT necessarily defined as Paramters. Thus, I think your point re: 957 and tags is not relevant.
These field values obviously have to provided as input from the OMS to the FIXatdl rendering component (but so do Region, Country, etc data points). FIXatdl specifies that you can reference such fields via “FIX_xxxx” where xxxx is the FIX spec’s standard field name. You can add to your edit checks checking to see if they are null/not provide as condition as well.
To accomplish this when processing the FIXatdl and sending my orders I could:
- check to see if one or more parameters have a fixtag then send all the have a fixTag ignoring those that don’t.
- if none of the parameters have fixTags require tag957Support=true otherwise complain.
Do you see any problems with this?
Indeed, but personally I think the spec is being too prescriptive - I have seen more than one implementation that allows the fixTag attribute to be omitted without expecting tag957Support to be set. I’d be interested to hear what others thing…
I think this might conflict with the spec. I am looking at the spec table on page 18. Seems like you would be unable to determine if the fixTag attributes are provided or not. Currently my code cycles through all parameters checking for fixTags. If one or more parameters are missing fixTags and the tag957Support is not true, I complain…
Then on page 31 describing Parameter/@fixTag:
Required when: parameter value is intended to be transported over the wire.
If fixTag is not provided then the Strategies-level attribute, tag957Support, must be set to true, indicating that the order recipient expects to receive algo parameters in the StrategyParameterGrp repeating group beginning at tag 957.So, if they provided no fixTags with tag957Support set to true, the “temp” parameter would be sent…
One common approach is for the control that doesn’t currently have a parameter, associate it with a ‘dummy’ parameter, but omit the fixTag attribute. That way the control can participate in StrategyEdit validation without being sent on the FIX wire.
I am working on validation rules. The validation is processed down stream against the parameters not the controls. I have run into a situation where I need a suggestion.
We have a set of controls as shown. If “Is Short?” is Yes, then the Locate ID is required. The “Is Short?” value is not associated with a parameter but the Locate ID is. So at the time of validation I don’t know if they they chose Yes so I can validate the locate id.
Is Short? o Yes o No Locate ID: [________]Any suggestions?
I am assuming this is a question related to FIXatdl. You could check the FIX Side field = ‘5’ (“Sell Short”). This assumes that the OMS is feeding/exposing key fields from the FIX order to the FIXatdl rendering component.
For instance:
<val:Edit field=“FIX_Side” operator=“EQ” value=“5” />
For this particular scenario I could compare against standard FIX_xxx order fields but there will be similar scenarios that don’t have that.
I think I may use the negative value for dummy parameters and update the engine to not send. Ideally it would be nice to have an attribut in the parameter element to flag to not send or transient…
Cathy, I think you misunderstood my suggestion. I was referring to the ability, within FIXatdl, to reference key fields from the New Order Single message which are NOT necessarily defined as Paramters. Thus, I think your point re: 957 and tags is not relevant.
These field values obviously have to provided as input from the OMS to the FIXatdl rendering component (but so do Region, Country, etc data points). FIXatdl specifies that you can reference such fields via “FIX_xxxx” where xxxx is the FIX spec’s standard field name. You can add to your edit checks checking to see if they are null/not provide as condition as well.
To accomplish this when processing the FIXatdl and sending my orders I could:
- check to see if one or more parameters have a fixtag then send all the have a fixTag ignoring those that don’t.
- if none of the parameters have fixTags require tag957Support=true otherwise complain.
Do you see any problems with this?
Indeed, but personally I think the spec is being too prescriptive - I have seen more than one implementation that allows the fixTag attribute to be omitted without expecting tag957Support to be set. I’d be interested to hear what others thing…
I think this might conflict with the spec. I am looking at the spec table on page 18. Seems like you would be unable to determine if the fixTag attributes are provided or not. Currently my code cycles through all parameters checking for fixTags. If one or more parameters are missing fixTags and the tag957Support is not true, I complain…
Then on page 31 describing Parameter/@fixTag:
Required when: parameter value is intended to be transported over the wire.
If fixTag is not provided then the Strategies-level attribute, tag957Support, must be set to true, indicating that the order recipient expects to receive algo parameters in the StrategyParameterGrp repeating group beginning at tag 957.So, if they provided no fixTags with tag957Support set to true, the “temp” parameter would be sent…
One common approach is for the control that doesn’t currently have a parameter, associate it with a ‘dummy’ parameter, but omit the fixTag attribute. That way the control can participate in StrategyEdit validation without being sent on the FIX wire.
I am working on validation rules. The validation is processed down stream against the parameters not the controls. I have run into a situation where I need a suggestion.
We have a set of controls as shown. If “Is Short?” is Yes, then the Locate ID is required. The “Is Short?” value is not associated with a parameter but the Locate ID is. So at the time of validation I don’t know if they they chose Yes so I can validate the locate id.
Is Short? o Yes o No Locate ID: [________]Any suggestions?
I am assuming this is a question related to FIXatdl. You could check the FIX Side field = ‘5’ (“Sell Short”). This assumes that the OMS is feeding/exposing key fields from the FIX order to the FIXatdl rendering component.
For instance:
<val:Edit field=“FIX_Side” operator=“EQ” value=“5” />
If your FIX engine supports it (some do), you could set the Y/N choice in a negative FIX tag of your choice in your parameter definition, which the FIX engine would not send, but you could store for your validation.
To accomplish this when processing the FIXatdl and sending my orders I could:
- check to see if one or more parameters have a fixtag then send all the have a fixTag ignoring those that don’t.
- if none of the parameters have fixTags require tag957Support=true otherwise complain.
Do you see any problems with this?
Indeed, but personally I think the spec is being too prescriptive - I have seen more than one implementation that allows the fixTag attribute to be omitted without expecting tag957Support to be set. I’d be interested to hear what others thing…
I think this might conflict with the spec. I am looking at the spec table on page 18. Seems like you would be unable to determine if the fixTag attributes are provided or not. Currently my code cycles through all parameters checking for fixTags. If one or more parameters are missing fixTags and the tag957Support is not true, I complain…
Then on page 31 describing Parameter/@fixTag:
Required when: parameter value is intended to be transported over the wire.
If fixTag is not provided then the Strategies-level attribute, tag957Support, must be set to true, indicating that the order recipient expects to receive algo parameters in the StrategyParameterGrp repeating group beginning at tag 957.So, if they provided no fixTags with tag957Support set to true, the “temp” parameter would be sent…
One common approach is for the control that doesn’t currently have a parameter, associate it with a ‘dummy’ parameter, but omit the fixTag attribute. That way the control can participate in StrategyEdit validation without being sent on the FIX wire.
I am working on validation rules. The validation is processed down stream against the parameters not the controls. I have run into a situation where I need a suggestion.
We have a set of controls as shown. If “Is Short?” is Yes, then the Locate ID is required. The “Is Short?” value is not associated with a parameter but the Locate ID is. So at the time of validation I don’t know if they they chose Yes so I can validate the locate id.
Is Short? o Yes o No Locate ID: [________]Any suggestions?
I am assuming this is a question related to FIXatdl. You could check the FIX Side field = ‘5’ (“Sell Short”). This assumes that the OMS is feeding/exposing key fields from the FIX order to the FIXatdl rendering component.
For instance:
<val:Edit field=“FIX_Side” operator=“EQ” value=“5” />
In general, validation can only occur by comparing the values of parameters. That is to say, values that go over the wire. State rule validation, which affects whether a control is enabled or visible, is done by comparing values of the various controls. There is no mixing and matching. (Unless you define some sort of dummy parameter - as Steve has mentioned.)
Since the particular validation you are attempting seems to involve Side and LocateID, two standard FIX fields, I would suggest creating an using FIX_Side, as Scott has indicated.
-Greg
I am working on validation rules. The validation is processed down stream against the parameters not the controls. I have run into a situation where I need a suggestion.
We have a set of controls as shown. If “Is Short?” is Yes, then the Locate ID is required. The “Is Short?” value is not associated with a parameter but the Locate ID is. So at the time of validation I don’t know if they they chose Yes so I can validate the locate id.
Is Short? o Yes o No Locate ID: [________]Any suggestions?
I am assuming this is a question related to FIXatdl. You could check the FIX Side field = ‘5’ (“Sell Short”). This assumes that the OMS is feeding/exposing key fields from the FIX order to the FIXatdl rendering component.
For instance:
<val:Edit field=“FIX_Side” operator=“EQ” value=“5” />
How about something like this:
(1) Assign the “Yes / No” chooser component a dummy parameter that you do not include in any layout so it doesn’t show in the screen.
(2) Now validate the value of that parameter (yes or no) against the LocateID field’s content.
(3) Optional: You could disable the LocateID field when the value of Is Short is No.
Cathy has a great question. My comment is more oriented to the WG in general.
Can’t a FLOW Rule be used here vs. a VALIDATION Rule?
FLOW was intended for Workflow - things happening during the order build process, from “nothing is filled in” through “all is filled in”.
VALIDATION on the other hand has always been “batch oriented”, to be run only after all parameters were flled in and available. Batch validation runs just prior to submitting the order live. The question always was when do the FLOW rules run. What event(s) fire them?
How about a FLOW rule (Not a VALIDATON rule) that checks the “Is Short radio group control” value? if “yes”, then something checks that the locate ID is OK. Why wait?
I assume the locate ID is a well known enumerated list fully expressed in the FIXatdl file. We clearly never supported dynamically populated enumerated lists from outsid the FIXatdl file in v1.1
As for Cathy’s specifics I graivate to Scotts solution. Was also thinking, didn’t we allow the Explicit inclusion of standard FIX parameters expressed in the FIXatdl file itself? (Enabling FIXatdl files to be 100% complete and able to render the entire ticket, including all standard fields, without referencing other areas?). Side might be an explictly stated FIX parameter. THen it would be right there to check against even if there was no “FIX_” facility.
Rick
My problem with using a state rule here is that we have several UI modules that allow for importing and/or batching orders. This may result in situations where the user does not open each order in the UI but all still need to be validated.
I did end up in the original case using a negative fix tag.
Cathy has a great question. My comment is more oriented to the WG in general.
Can’t a FLOW Rule be used here vs. a VALIDATION Rule?
FLOW was intended for Workflow - things happening during the order build process, from “nothing is filled in” through “all is filled in”.
VALIDATION on the other hand has always been “batch oriented”, to be run only after all parameters were flled in and available. Batch validation runs just prior to submitting the order live. The question always was when do the FLOW rules run. What event(s) fire them?
How about a FLOW rule (Not a VALIDATON rule) that checks the “Is Short radio group control” value? if “yes”, then something checks that the locate ID is OK. Why wait?
I assume the locate ID is a well known enumerated list fully expressed in the FIXatdl file. We clearly never supported dynamically populated enumerated lists from outsid the FIXatdl file in v1.1
As for Cathy’s specifics I graivate to Scotts solution. Was also thinking, didn’t we allow the Explicit inclusion of standard FIX parameters expressed in the FIXatdl file itself? (Enabling FIXatdl files to be 100% complete and able to render the entire ticket, including all standard fields, without referencing other areas?). Side might be an explictly stated FIX parameter. THen it would be right there to check against even if there was no “FIX_” facility.
Rick