I have used IBM Watson Retrieve and Rank Web Interface to create a collection of html articles. Via the web interface I was able to upload my html articles. The problem is when I query the collection the data for id and title are not usable. Here is the query I made in the browser:
https://MY-USER-NAME:MY-PASSWORD#gateway.watsonplatform.net/retrieve-and-rank/api/v1/solr_clusters/MY-CLUSTER/solr/MY-COLLECTION/select?q=what is the basic mechanism of the transonic aileron buzz&wt=json&fl=id,title
The response I get is:
{"responseHeader":{"status":0,"QTime":106,"params":{"q":"what is the basic mechanism of the transonic aileron buzz","fl":"id,title","wt":"json"}},"response":{"numFound":12,"start":0,"docs":[{"id":"6a06f47c-cb3f-4791-9914-c84772eb9415","title":"no-title"}.....
The bold section is the problem. When using the web interface is there a way to set the title and id when uploading documents? Or, better yet, is there another way I query my collection to get the file name of the document I uploaded and/or the text from the document?
When using the web interface is there a way to set the title and id when uploading documents?
No, sorry.
However, if you upload the documents yourself from outside of the web interface, you can specify the title and ID (and the documents will be shown in the web interface when you come back to it).
is there another way I query my collection to get the file name of the document I uploaded
Yes
In the query you posted above, the last parameters you have are the fields you want to retrieve
&fl=id,title
You're retrieving the ID and the title.
If you want the name of the file that the content came from, add fileName. For example:
https://MY-USER-NAME:MY-PASSWORD#gateway.watsonplatform.net/retrieve-and-rank/api/v1/solr_clusters/MY-CLUSTER/solr/MY-COLLECTION/select?q=what is the basic mechanism of the transonic aileron buzz&wt=json&fl=id,title,fileName
is there another way I query my collection to get text from the document
Yes.
Similar to above, you just need to update the list of fields that you retrieve. The contents of the doc is put in a field called body.
So to get the ID, title, and the body, you could use:
https://MY-USER-NAME:MY-PASSWORD#gateway.watsonplatform.net/retrieve-and-rank/api/v1/solr_clusters/MY-CLUSTER/solr/MY-COLLECTION/select?q=what is the basic mechanism of the transonic aileron buzz&wt=json&fl=id,title,body
That gets you a plain text version of the contents. If you want the HTML, use contentHtml instead.
https://MY-USER-NAME:MY-PASSWORD#gateway.watsonplatform.net/retrieve-and-rank/api/v1/solr_clusters/MY-CLUSTER/solr/MY-COLLECTION/select?q=what is the basic mechanism of the transonic aileron buzz&wt=json&fl=id,title,contentHtml
Related
When you use salesforce data that has being exported through any API, tables you get have column names in their "API_Name" format. This differs a bit from their "Filed Label" format in which they are presented on salesforce's web UI (for example on reports).
You can find what API name corresponds to any of the columns (objects) in the salesforce object manager.
My question is: is there anywhere a dictionary to map API Names back to their Filed Labels? It will be very helpful to have in JSON or anything that can be used programmatically.
It's called "describe" data. It's available for whole object (label, plural label), fields (label, picklist value translations), names of related lists.
In Apex this is a good initial reading: https://developer.salesforce.com/docs/atlas.en-us.200.0.apexcode.meta/apexcode/apex_dynamic_describe_objects_understanding.htm and for fields: https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_methods_system_fields_describe.htm
If you're using REST API - make GET to /services/data/v55.0/sobjects/Account/describe for example.
Have a look at https://developer.salesforce.com/docs/atlas.en-us.uiapi.meta/uiapi/ui_api_quick_start.htm too. For example if you need to build your own UI for "dependent picklists" it can be painful to read it all from "describe", https://developer.salesforce.com/docs/atlas.en-us.uiapi.meta/uiapi/ui_api_features_records_dependent_picklist.htm is bit better. And when you fetch records via this API you get fields as object with visible label and raw value (useful when displaying dates, numbers for example)
For a RESTful API, consider a model schema as follows:
MyCoolObject {
field_a
field_b
field_c
}
Is it better to create one update endpoint to update one or many fields on the model (PUT)? Or create one endpoint per field that would only update that one field (PATCH)?
Heuristic: how do you GET the information from your API?
Typically if you get the information a single resource with all of the information included in its representation...
GET /my-cool-object
Then you should also edit that information using the same resource
PUT /my-cool-object
PATCH /my-cool-object
POST /my-cool-object
In cases where you get the information from multiple resources (presumably via links)
GET /my-cool-object
GET /my-cool-object/a
GET /my-cool-object/b
GET /my-cool-object/c
Then you would normally edit the information in its own resource
PUT /my-cool-object/a
PATCH /my-cool-object/a
POST /my-cool-object/a
Azure Search by default highlights search results with <em> tag. I've met with situation where user uploads document with that tag inside:
<em>Today</em> topic will be...
When i would search for "topic" i would get:
<em>Today</em> <em>topic</em> will be...
And i wouldn't be able to distinguish the right highlight.
I know that i can modify highlight_pre_tag and highlight_post_tag so i would avoid this in this particular situation. But is there other way to encode this tags before appyling highlighs?
EDIT:
By encoding i mean getting something like this:
<em>Today</em> <em>topic</em> will be...;
So I can send it to frontend and then display <em> from "Today" as <em> and use <em> in "topic" to highlight it to yellow.
Azure Search doesn't provide any built-in mechanism to modify the "raw" content of a document if you are using the Index API directly, however, if you are using one of our built-in indexers, you can look into using the field mapper functions (such as the UrlEncode function) or create your own custom skill (if you want to only apply very specific rules) to transform the documents in transit from your data source to the search index.
Alternatively, we've seen customers use custom highlight pre and post tags that are easily recognizable (and unlikely to be mistaken for original content) and then using a simple search and replace function in their client application to transform those back into the desired tag.
For example, using
pre-tag : "!HIGHLIGHT_START!" and post-tag :"!HIGHLIGHT_END!"
and then using
String.Replace("!HIGHLIGHT_START!", "<em>")
before displaying the results in their application. That way, any client-side logic that requires finding the actual highlights can use the custom tags, while still showing the desired tag in the UX.
I am extending Kiwi TCMS for my team and trying to display the Product on the Search Test Cases page. The Product is tied to the Category field and I am not sure how to extract that field within the testcases/static/js/seach.js file.
I have traced it back to jsonrpc.js but am missing something, not sure what it is I am not seeing.
I added the Product field in the search.html file and the data is moved 1 column to the left since the array does not contain the Product field. I have tried "product" and "product_id" in the columns[] section of search.js.
Thanks
I have traced it back to jsonrpc.js but am missing something, not sure what it is I am not seeing.
JSON RPC is a communications protocol. The spec is very simple, you can find it at https://www.jsonrpc.org/specification. The jsonRPC function in Kiwi TCMS is a wrapper for that.
FK relationship between models are represented with a field called ..._id. For example Category has a field product_id. At the same time the Product model has a reverse relationship to Category - this is something that the underlying web framework adds automatically. The field is called Product.category.
Checkout how to make queries here:
https://kiwitcms.readthedocs.io/en/latest/modules/tcms.rpc.api.html#module-tcms.rpc.api
If you have test_case.category_id then you can send another API request to Product.filter method filtering on the category field with the respective value.
Inside the browser console you can do something like:
jsonRPC('Product.filter', {category: 1630}, console.log)
and see the results you get.
I added the Product field in the search.html file and the data is moved 1 column to the left since the array does not contain the Product field. I have tried "product" and "product_id" in the columns[] section of search.js.
You will have to modify the entire page (which includes search, the callback, the HTML template and the function rendering the returned data) for this to work.
It sounds like either
you need more information shown in the search table: there isn't much space available, OTOH there is a filter per Product so if you teach users to filter by product everything they see will be related to that product so they won't need additional column for that information
you need a more flexible mechanism for extension - it is mostly doable and possible to design pages in Kiwi TCMS to be arbitrarily extensible, however we haven't thought in this direction and we need more information about the intended use-case to figure out the underlying architecture.
you can design an entirely separate search page, using the upstream code as your base. Then bundle that into a plugin and just install your plugin into Kiwi TCMS. That actually sounds like the best option in this case and you will have full control over that page, see https://kiwitcms.readthedocs.io/en/latest/plugins/index.html.
I am looking to create a feature whereby a User can download any available documents related to the item from a tab on the PDP.
So far I have created a custom record called Documentation (customrecord_documentation) containing the following fields:
Related item : custrecord_documentation_related_item
Type : custrecord_documentation_type
Document : custrecord_documentation_document
Description : custrecord_documentation_description
Related Item ID : custrecord_documentation_related_item_id
The functionality works fine on the backend of NetSuite where I can assign documents to an Inventory item. The stumbling block is trying to fetch the data to the front end of the SCA webstore.
Any help on the above would be much appreciated.
I've come at this a number of ways.
One way is to create a Suitelet that returns JSON of the document names and urls. The urls can be the real Netsuite urls or they can be the urls of your suitelet where you set up the suitelet to return the doc when accessed with action=doc&id=_docid_ query params.
Add a target <div id="relatedDocs"></div> to the item_details.tpl
In your ItemDetailsView's init_Plugins add
$.getJSON('app/site/hosting/scriptlet.nl...?action=availabledoc').
then(function(data){
var asHtml = format(data); //however you like
$("#relatedDocs").html(asHtml);
});
You can also go the whole module route. If you created a third party module DocsView then you would add DocsView as a child view to ItemDetailsView.
That's a little more involved so try the option above first to see if it fits your needs. The nice thing is you can just about ignore Backbone with this approach. You can make this a little more portable by using a service.ss instead of the suitelet. You can create your own ssp app for the function so you don't have to deal with SCAs url structure.
It's been a while, but you should be able to access the JSON data from within the related Backbone View class. From there, within the return context, output the value you're wanting to the PDP. Hopefully you're extending the original class and not overwriting / altering the core code :P.
The model associated with the PDP should hold all the JSON data you're looking for. Model.get('...') sort of syntax.
I'd recommend against Suitelets for this, as that's extra execution time, and is a bit slower.
I'm sure you know, but you need to set the documents to be available as public as well.
Hope this helps, thanks.