When I check the data dictionary https://github.com/quickfix/quickfix/blob/master/spec/FIX42.xml
It looks like to me that there are only field name and whether it is a required field or not.
But as I know, a FIX message is only a series of fields with key and value separated by delimiter
How can QuickFix map the field number to name as the data dictionary does not contains any info about the field number? I mean at least something like <field number='8' name='BeginString' required='Y' />
Or the FIX elements must be specified in order so that the data dictionary just maps them one by one in order? But if it is the case, how about one element is missing, then all the subsequent mappings go wrong?
Any help is highly appreciated.
The answer is basically in the same file that you mentioned in your post.
Field names are mapped to numbers starting from here: https://github.com/quickfix/quickfix/blob/85bb8a9acae6b0e6a2c37d498e646a5437f23983/spec/FIX42.xml#L1603
Related
I would like to receive your help in order to create an aggregate field in the Tableau tool.
I have a data source. The data source contains a few records (tuples/lines), and each record contains some attributes. I.e. a numeric value, a unique attribute (Key) and string.
For example, the first two rows share the same key (ID=A). This entity contains 2 records, the numeric value for each record is different (1 and 5).
I would like to create a new field. This new field should contain the minimum numeric value for each unique ID (entry).
In order to create this new field, I created a calculated field. The field’s formula is- min(NumericField).
The problem occurred when I was trying to use this calculated aggregated field aggregate in order to create chats. In this case, the aggregation is no longer performed on my key field.
For example, I would like to calculate the average for each category (The avg should be calculated for the aggregated new field)
Do you have any idea in order to resolve the mentioned problem?
Thank you! ☺️
An example
Try using LOD as below:
{fixed [id]: avg([newcalculatedfield])}
Let me know if you need more help. thanks!
so my company wants me to learn ABAP for SAP and I have started on the road to learn this. My background is mainly VB.net and sqlserver with T-SQL but also have experience in c#.
With ABAP though I am needing some clarification or confirmation on the understanding of Data Types and Domain. If anyone can help.
My understanding currently is we have a table, in the table we have fields and the fields have data types and lengths if needed. Example: We have a table Customer, I could have a customerNumber field with the data type of char(10). To me this mean in the table customer we have a field called CustomerNumber that will have 10 characters.
However with ABAP we have Domains, Data elements then the field, does this mean we have a field named whatever we want. As the field could mean anything we assign a data element which has the descriptions of the sort of data stored within the field. However to store the format and data type we need to assign the Domain to the Data element.
For example I call a field ZCUSNO, currently this means nothing however if I assign the ZCTNMR (with description of customer number) Data element this tells us that the field ZCUSNO is ZCTNMR so ZCUSNO is a customer number field.
Now within the data elements we would have a domain and for our example ZCTNMR data element (the customer number) we could assign ZCTDOM as the domain which would be what I recognise as the data types so Char 20, Char 100 or integer field etc.
Is my understanding correct on this? and could someone give me a clear indication of what the difference between a Domain > Data Element is against what I would know as data types in sqlserver.
Thanks
I don't know if it's 100% correct, but that's is the way I use, like you say.
You can reuse the Domain, If you don't plan to reuse you can use direct the Data Element and refer this to a built-in-type.
Data Element is to define semantic of the field, like label, translation, etc
Domain is to define techinical info of the field, like Type, conversions, predefined Values,e tc
E.G.
Domain:
DOM_VALUE you define it's 10 position and 2 Decimals
Data Element:
UNIT_VAL you refer it to DOM_VALUE and define label as "Unit Value"
TOTAL_VAL you refer it to DOM_VALUE and define label as "Total Value"
Your understanding is pretty correct and not much can be added here.
You should clearly get the main thing.
Domains store technical data (decimal points, length, type, predefined values and so on)
Data elements store semantic data (labels, texts, search help binding, etc.)
Not every table field has data element (they can possess builtin type) but every field has type (either primitive or wrapped in data element).
If you wanna use your field in screens (Dynpros), ALV grids or other reports, then create data elements that will bear business meaning of your field.
If you use this field just for calculations or other utility internal tasks, then don't bother yourself.
As usual table date field (type of variable) uses data element which uses domain.
When you create fields in table and use predefined types instead of data elements you will have some problems in future, when you'll need to see the data on alv_grid.
Actually, you will see that you have some problems even before this (when you will try to make a maintenance view the header will have something like "+" symbol).
And of course we usually try to create 1 domain for 2 and more Data Elements.
In domain you talk about main logic.
In Data Element I always talk about Field label settings (how it'll show in future and some other things)
Final: Actually, the good practice, as I think to create a domain for data element, it may help you in future.
I hope that it helps you. Good luck!
Anyone been able to successfully update the custom_field_values for a matter via Clio's API?
I'm trying to update the value for custom_field_values under a single matter. I'm able to send a JSON string using PATCH and update the default values for a matter like location or description using the following format
{"data":{"location":"Orange"}}
But when it comes to updating a "custom field value" I'm getting a 422 Unprocessable Entity error. I'm following Clio's v4 API Documentation and my understanding is that to update a custom_field_value you need the following JSON:
{"data":{"custom_field_values":[{"id":658213,"custom_field":{"id":139385},"value":"New Value Goes Here!"}]}}
However here is the message coming with the 422 error:
{"error":{"type":"ArgumentError","message":"An invalid argument was supplied: invalid custom field value id provided, acceptable format is <type>-<unique id>"}}
I can't interpret the part suggesting the acceptable format!
I've also tried sending the JSON in the following format which is closest to Clio's V2 API Docs for updating a custom field:
{"data":{"custom_field_values":[{"custom_field":{"id":139385},"value":"New value goes here"}]}}
But then this is what I get back:
{"error":{"type":"ArgumentError","message":"An invalid argument was supplied: custom field value for custom field 139385 already exists"}}
Please note that this is being tested in POSTMAN regardless of my development environment. I appreciate your response!
I've successfully created queries to update custom field values in matters many times, and these run all the time for me. I've compared your json to some examples of the json I'm successfully sending. Your syntax appears correct, but there's enough missing for me to only guess at where your mistake might be.
First, you're sending a PATCH to https://app.clio.com/api/v4/matters/{matter id}.json right? It took me a while to learn that you can't update the value of a matter's custom field with a query to https://app.clio.com/api/v4/custom_fields/{id}.json.
Second, just to clarify, the 658213 id you used above (the first id field) should be the unique id of this instance of your custom field. You won't get this until you've created an instance of the custom field particular to this matter. The second id field, where you've put 139385 is the id for the custom field itself, which you could get with a query to https://app.clio.com/api/v4/custom_fields.json.
If you're looking in the V.4 docs under Custom Fields, you won't find this, or at least I didn't. BUT you can find it in the intro section to the Matters portion fo the documentation: https://app.clio.com/api/v4/documentation#tag/Matters
Hope this helps. I'd imagine someone at Clio could help by verifying your error string is delivered when you have an incorrect custom field value unique id.
To further clarify Jacob's answer for everyone else:
custom_field{id} is the id given to a custom_field when it's created and will be the same for all matters or contacts it's used in.
custom_field_value{id} is the id given to an instance of the custom_field added to a particular matter and unique only to that matter
To add a custom_field to a matter for the first time the following format is used:
{"data":{"custom_field_values":[{"custom_field":{"id":123456},"value":"string or integer depending on the type of CF"}]}}
To update a custom field already added to a matter the following format should be used:
{"data":{"custom_field_values":[{"id":"text_line-1234567", "custom_field":{"id":123456},"value":"string or integer depending on the type of CF"}]}}
To delete a custom field already added to a matter the following JSON format is sufficient:
{"data":{"custom_field_values":[{"id":"text_line-1234567", "custom_field":{"id":123456},"_destroy":true}]}}
Format for updating a custom field already added to a matter:
{"data":{"custom_field_values":[{"id":"unique_instance_of_your_custom_field", "custom_field":{"id":'custom_field_id'},"value":"value which should be updated"}]}}
Here, the first id field should be the unique id of this instance of your custom field. To get this value follow this documentation section, app.clio.com/api/v4/documentation#tag/Matters and the second id field is the id for the custom field itself.
I have a table in a word document that has three colums and all fields are mailmerge fields from an external IT system.
There are three columns displaying the fields:
Charge Description
Charge Value (£)
Eiligible? (yes/no)
I am trying to create a field that adds up all eligibale charges so that only charge values that show a "yes" in the eligigble field are included. Does anyone know if this is possible? I have tried creating a formula but can't get it to work. Also, I would assume at some point an if statment is required so that it only includes the eligible charge.
Has anyone done anything similar before and if so, would they mind sharing how it was achieved?
Many thanks
You can do some things with expression fields (created in Word with CTRL-F9). This will look like {} and you can insert the expression. eg {{MERGFIELD charge} + {MERGEFIELD charge2}}. Since however you want to check multiple values and then create an expression, its probably easier to use a macro. The macro would contain your logic, then set the fields in the document accordingly.
Here are two external links since I can't reproduce a useful amount the content here because it's a verbose answer to a potentially deep question:
Expression Fields
Merge fields
I hope that helps.
the documentation says
object containing fields whose names are the indexes to where objects are mentioned in the message field; each field in turn is an array containing an object with id, name, offset, and length fields, where length is the length, within the message field, of the object mentioned
what's missing though is how do we need to encode it? should it be a JSON object?
As far as I'm aware, that's a read-only field for reading the list of pages/profiles tagged in a post, did you find documentation suggesting it was writeable?