[INTM] Add new object type INTM #671
Conversation
Done the changes. Please review and let me know in case of any changes required. |
There was a problem hiding this comment.
Please see below some more general questions/remarks based on your example object.
Some of them we addressed in our meeting last week (like the GUID and the "Published" property). Some might be new. Structure-wise I think the prompt parameters are worth to look into. Maybe, we can get rid of the JSON content field by replacing it in a well structured information that is much more readable, but I am not sure, whether this is technically possible.
file-formats/intm/examples/saplvfkd32izflkp5or2uqi1jlc4.intm.json
Outdated
Show resolved
Hide resolved
file-formats/intm/examples/saplvfkd32izflkp5or2uqi1jlc4.intm.json
Outdated
Show resolved
Hide resolved
file-formats/intm/examples/saplvfkd32izflkp5or2uqi1jlc4.intm.json
Outdated
Show resolved
Hide resolved
file-formats/intm/examples/saplvfkd32izflkp5or2uqi1jlc4.intm.json
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
@raghav6686 Just a minor comment. I think this can be fixed (if it helps you), later. But before merging this PR.
I will also reopen one older comment and provide you a suggestion. To make it more clear to you what I meant. With the prompts. This can also be fixed next week.
| "promptTemplateName": "USER_PROMPT", | ||
| "promptTemplateDescription": "User prompt", | ||
| "prompt": "Build a confirmation mail for a sales order containing {ISLM_Items} where the items are categorized for example pencil and paper will be stationary, printer and mouse will be electronics. The source address contains {ISLM_Source} and the delivery address is in {ISLM_Destination}.", | ||
| "promptParameters": "[{\"Name\":\"ISLM_Items\",\"Value\":\"\"},{\"Name\":\"ISLM_Source\",\"Value\":\"\"},{\"Name\":\"ISLM_Destination\",\"Value\":\"\"}]", |
There was a problem hiding this comment.
Related to #671 (comment). If it is always name-value or an empty list , it could look like this in AFF:
| "promptParameters": "[{\"Name\":\"ISLM_Items\",\"Value\":\"\"},{\"Name\":\"ISLM_Source\",\"Value\":\"\"},{\"Name\":\"ISLM_Destination\",\"Value\":\"\"}]", | |
| "promptParameters": [ | |
| { "Name": "ISLM_Items", | |
| "Value": "" | |
| }, | |
| { "Name": "ISLM_Source", | |
| "Value ": "" | |
| }, | |
| { "Name ": "ISLM_Destination", | |
| "Value": "" | |
| } | |
| ]", |
There was a problem hiding this comment.
Can be discussed next week
There was a problem hiding this comment.
Actually, our logic in AFF persistence class only builds the JSON and pass to string field, which is necessary for passing the parameters in the prompt execution.
Does AFF/ADT framework stringify the JSON in the source? I mean the / in the output.
Also another comment on this VALUE field - This is empty as of now, but as I mentioned earlier, we will definitely implement the default values option as user input in the ADT UI. Similar to our Fiori UI,
So, this default parameters is future scope for ADT.
There was a problem hiding this comment.
Does AFF/ADT framework stringify the JSON in the source? I mean the / in the output.
Since you put JSON in a string field consisting of certain characters (to be precise: quotes (")), these quotes must be escaped by \.
Nevertheless, even without escaping, it would be nicer if you don't put the JSON into a string, but just using it as real JSON. Still, I am not sure whether this is possible in your case, but maybe it's worth to discuss.
Did you get my idea?
There was a problem hiding this comment.
Yes, I got your point that you want to keep it as real JSON. We kept it as string because we do store the prompt parameters in DB as a string.
If we keep it as real JSON, then we need to serialize it and store in the DB.
Also, AFF has to be changed for prompt_parameters field, which needs to be declared as a deep table within prompts table. Is it possible?
There was a problem hiding this comment.
Sorry, I didn't manage to answer earlier. :(
Yes, I think you would need to serialize it, if you would change it. I am still not 100% sure whether it is feasible at all to follow my suggested approach in your case. But if it is feasible, I would recommend it.
Maybe, it is worth to discuss my idea in a call. Then we can see the advantages and disadvantages of both approaches. What do you think?
No description provided.