I have used the Form Recognizer labeling tool to create train and create models. At the time I started I had used the 2.1 preview and the API version was v2.1-preview.3
To use the models created with the labeling tool via the analyze REST api I used the url endpoint and API version as:
https://{endpoint}/formrecognizer/v2.1preview3/custom/models/...
Now the 2.1 GA version of the labeling tool is available.
Is the version of the API used by the from labeling tool fixed based on which version of the labeling tool docker image we run?
If I use the docker image {mcr.microsoft.com/azure-cognitive-services/custom-form/labeltool:latest-2.1}, the API endpoint will be
https://{endpoint}/formrecognizer/v2.1/custom/models/...
AND
If I use the docker image {mcr.microsoft.com/azure-cognitive-services/custom-form/labeltool:latest-preview} then it is the last preview and the API endpoint will be
https://{endpoint}/formrecognizer/v2.1-preview.3/custom/models/...
Or is there someway I can set explicitly set the API version so I can be sure which API version is being used by the labeling tool?
Is there any settings that I am missing where I can set or at least confirm which version is being used by the tool?
The .fott file has a version property which is set to "2.1.0" in the project created with the preview version and "2.1" with the GA version. Does this property indicate anything?
Thanks
The project (.fott) file has an optional property "apiVersion", you can set it to "v2.1" or "v2.1-preview.3" based on your needs :)
If this property is not set in the project file, label tool will use the default version which will be the same as tool version.
note: the "version" property in .fott doesn't represent the API version, instead it's just reflect the source control version.
Thanks!
Related
According to the integration guide for Contacts OData the Sap-Cuan-SequenceId header is mandatory when updating a ContactOriginData record. When updating in singleton mode I am able to set this header as follows and it works without issue:
service
.updateContactOriginData(contact)
.withHeader("Sap-Cuan-SequenceId", "PatchUpdate")
.executeRequest(destination);
However, there is no option to set this header when performing the same update in batch mode:
service
.batch()
.beginChangeSet()
.updateContactOriginData(contact)
.withHeader(...) // this option does not exist
.endChangeSet()
.executeRequest(destination);
When I run the batch one my SAP Import Monitor shows the error:
Invalid content in field Sap-Cuan-SequenceId
Is it possible to set this header in batch mode and I'm just not seeing how? I am using version 3.39.0 of the SDK. Any help would be greatly appreciated!
Thanks!
This clearly looks like an implementation shortcoming. The SDK has a new API for OData BATCH in the OData v4 client which shouldn't have this issue. Mentioned service exposes OData v2 only and the OData v2 BATCH implementation has been historically different. For compatibility reasons, it has to be kept like this. We plan to provide a parallel implementation to align it with OData v4 and fix many minor and major inconsistencies.
If this is super urgent we can try to provide a workaround using the SDK's generic OData client otherwise create an issue in this GitHub repository and the SDK team will update you when the fix for adding headers is going to be released.
I need to develop an API using NodeJS.But I am not an expert in the nodejs. For the versioning of the API, I found one method where we should keep 2 folders for V1 and V2 versions. Is this the best practise to follow for my API development. Please suggest the best approach? and also suggest the project structure.
Thanks in advance
You should keep the API version as a variable that is configurable (ex. in .env file). You can then version your API by adding the version to the path of your root endpoint (ex. /my-api/v1/api-resource). And when a new version of the API is developed just change the version to v2.
I think that solution of two different directories is not good, because you would have to copy code around and it can quickly mess things up. If you want to have different versions of the API separated you should use some type of version control and develop your v1 on a separate branch (ex. v1) and when the development of that version is complete just create a new branch for the new version (ex. v2).
You should also look into REST as the architectural style of your API: https://restfulapi.net/
I have also created a template for the development of backend systems in Node.js that is based on REST architecture, so you can check out the directory structure and architecture of Node.js projects.
I'm currently training a custom model (manual labeling) using the OCR labeling tool
I noticed the model was stored on the https:///formrecognizer/v2.0-preview/custom/models endpoint.
The Form Recognizer .NET SDK (Microsoft.Azure.CognitiveServices.FormRecognizer v0.8.0-preview) are currently directed to the v1.0.0-endpoint because the model id is not available when I executed a GET request to https:///formrecognizer/v2.0-preview/custom/models and It did exists on https:///formrecognizer/v1.0-preview/custom/models. Does anybody know how to fix this problem without having to implement the REST API manually all over again or waiting for the next version of nuget package to come out?
Any help would be appreciated!
You can check out this website for the code snippets of how to use the v2.0 REST API:
aka.ms/Form-aka.ms/Form-Recognizer/api
The current SDK only supports v1.0 release, but the SDK for v2.0 release is coming soon. Stay tuned.
The new Azure SDK Azure.AI.FormRecognizer preview library supporting Form Recognizer service version 2.0-preview is now available. Details on how to use it can be found in the package README.
I am taking this one straight from the repo.
I am using this scenario Azure Samples and when I try to upload the base I get the following error (cut for brevity):
The specified page contract 'urn:com:microsoft:aad:b2c:elements:contract:unifiedssp' has invalid version '2.0.0'. The available versions are: '["1.0.0","1.1.0","1.2.0"]'.
Any thoughts on this?
The current available versions for page layout are ["1.0.0","1.1.0","1.2.0"]. You can find the version change log here.
Try to change the version from 2.0.0 to the available version in PasswordlessEmailAndPhoneBase.xml file.
Does anyone have experience, information or some (coding) examples about a solution to establish a connection between the appserver of progress and node.js!? The aim is to create REST-Services to the db which can be accessed by the web like an angular-app.
Thanks for any advice
Christian
Starting with 11.2 (and enhanced in later versions) you can create REST-based applications utilizing the AppServer as a platform. ProDatasets are used as output (they convert easily to xml and/or json).
This is all explained in the Web Services part of the documentation. I'm providing a link below.
Basic steps
You need to consult the manual for all these steps...
Create an ABL program with input parameters (could be a parameter, a temp-table or a dataset) and and a single output parameter (could be a temp-table, a dataset or a single character or longchar parameter).
Add ABL-specific REST annotation to the program
Map the parameters in OpenEdge Studio
Setup REST agents with the restman utility
Export a "WAR-file" and deploy your webservice.
Calling the web service from node.js should be no greater problem than calling any REST based web service.
In versions prior to 11.2 you can "fake it and make it" utilizing WebSpeed. You can create a webspeed program that read parameters from the query-string (using get-field()) and then writes a response to the "webstream". Use either the WRITE-XML or WRITE-JSON methods on a temp-table or a dataset for writing the result. Don't forget to add a good MIME type though... This might not be as robust and customizable but it will work...
OE 11.4 Product Documentation - Web Services See chapter "II Creating OpenEdge REST Web Services"
These might also be useful:
OE 11.4 Product Documentation - Working with XML
OE 11.4 Product Documentation - Working with JSON