I see the Viewer still uses 'AutodeskProduction' environment which uses Viewing Service v1, not 'AutodeskProductionV2' which uses Derivative Service v2.
I try 'AutodeskProductionV2' and see it fails (404 Not Found) to GET at /derivativeservice/v2/:urn
With Model Derivative API, we POST job at /modelderivative/v2/designdata/job, but the translated data still get(s) from /viewingservice/v1/:urn, not from /derivativeservice/v2/:urn
The OSS still map to /oss/v1, regardless of whether the OSS bucket is in v1 or v2.
When will we use the full version of v2 of Data Management and Model Derivative API? Thank you.
For the short answer, read the last paragraph.
i have been using my Node.js command line sample and cannot reproduce what you are describing.
I executed the following commands:
node forge-promise.js 2legged
node forge-promise.js bucketCreate cyrille20160916a
node forge-promise.js upload samples/Au.obj
-> get a response with location = https://developer.api.autodesk.com/oss/v2/buckets/cyrille20160916a/objects/Au.obj
node forge-promise.js translate Au.obj
-> get a response with urn = dXJuOmFkc2sub2JqZWN0czpvcy5vYmplY3Q6Y3lyaWxsZTIwMTYwOTE2YS9BdS5vYmo
node forge-promise.js translateProgress Au.obj
-> when I got a completed translation
node forge-promise.js manifest Au.obj
node forge-promise.js html Au.obj Au.test
-> here I generate a file using the recommended production server and latest viewer version 2.9
Using the https://developer.api.autodesk.com/viewingservice/v1/... is fine but not recommended for production. v1 in this case is unrelated to the REST API you are using for OSS or DM... it is the viewing service version, so you do not need to worry.
OSS version v2 is not available and should be preferred to version v1 (see documentation here for v2 OSS. You will see for example that it says https://developer.api.autodesk.com/oss/v2/buckets/.
Now the DataManagement API is versioned as v1 (i.e. https://developer.api.autodesk.com/project/v1/hubs) but that does not has any relation to the Model Derivative v2 API. v1 in this case only means that we have release:
OSS v2
Data Management v1
Model Derivative v2
and are the latest API available. With REST API, data is backward/forward compatible, only the REST call are versioned, but should work fine all together. For example and highly not recommended for future, you may decided to use the old viewing service v1 to start the translation, using OSS v2 or v1, and everything should continue to work today (as September 2016), but these 'old' API will be retired in future.
Now if you got a a problem with one or another API, maybe you can share with us a code sample / snippet, so I better understand the issue.
An error 404, means that the resource wasn't found, which can translate in multiple causes. For example a base64 encode string, a non urlencoded parameter - but with the new Model Derivative API (i.e. v2) when you post a translation job, and request the manifest immediately after, you will get a 404 error because the manifest does not yet exist. It would exist only when the translation Job has really started on the server. And depending how busy is the server, it can take many 'seconds' (up to a minute or two). I believe this is the issue you are facing, but if not please provide me a code sample.
Related
I would like to to read my bim360 models which is in otg format in my Forgeviewer (version 7.3). The projects have been converted using the https://otg-bim.herokuapp.com/ app.
Is there any guidelines of how to make my Forge viewer read otg format from Bim360? I found this guideline (https://github.com/wallabyway/OTG-client-sample/blob/552c78b1fe8e1177f6694fd947a17fd189a8505b/public/js/ForgeViewer.js#L26-L29), however it uses Autodesk.Viewing.ViewingApplication which I find in version 2 of the Forge API, but not in version 7.3.
You can use this version of the ForgeViewer.js to work with latest versions of the viewer. https://github.com/jaimerosales/OTG-client-sample/blob/master/public/js/ForgeViewer.js
It seems that it is the same svn. Fault was that options requires autorization, even though I am allready autorized through bim360 login. Providing the access token there, uncomment useCookie and useCrentials and it works.
const options = {
env: 'FluentProduction',
api: 'fluent',
//useCookie: false,
//useCredentials: false,
accessToken: "add access token even though you are allready authorized in in bim360"
};
So far, I have seen a significant improvement loading using otg :-).
The latest version of svf2 works fine when using buckets instead of bim360. I have not vertified it with bim360. Example code which was helpfull for me was this npm package. https://www.npmjs.com/package/ng2-adsk-forge-viewer
I am using tessera for execute private transaction's in Quorum. When invoking the third party (privateURL) API from the postman, I am getting the expected output but when calling the same API's from the other server I am getting an empty response with 200 status code( http://:9081/storeraw). This issue is happening due to the CORS. I've checked with:
File:///< HTML_PATH >
and it's working.
How to enable CORS for tessera third party API's?
Currently, this feature is not implemented in tessera. I'm working already I'll get back to you once it's done. For enabling CORS follow steps below.
Clone repository from git.
open the file /jaxrs-service/src/main/java/com/quorum/tessera/thridparty/RawTransactionResource.java
Replace
return Response.status(Status.OK)
.type(APPLICATION_JSON)
.entity(response)
.build();
with
return Response.status(Status.OK)
.type(APPLICATION_JSON)
.header("Access-Control-Allow-Origin", "*")
.entity(response)
.build();
Recompile the code
Start tessera.
Note: This will allow all origins, please modify the code as per your security needs. This is not a standard, I am working on config changes that will allow you to have the freedom to enable CORS with corresponding changes.
My app successfully integrates the Google Maps JS API/Google Places API Web Service to create a few Autocomplete dropdowns. I have my google api browser key set up so development (localhost), staging, and production urls work. However, on any page this service is utilized, acceptance tests (using 127.0.0.1) break. For example:
Capybara::Poltergeist::JavascriptError:
One or more errors were raised in the Javascript code on the page. If you don't care about these errors, you can ignore them by setting js_errors: false in your Poltergeist configuration (see documentation for details).
Google Maps API error: RefererNotAllowedMapError https://developers.google.com/maps/documentation/javascript/error-messages#referer-not-allowed-map-error
Your site URL to be authorized: http://127.0.0.1:52724/clients/3
Google Maps API error: RefererNotAllowedMapError https://developers.google.com/maps/documentation/javascript/error-messages#referer-not-allowed-map-error
Your site URL to be authorized: http://127.0.0.1:52724/clients/3
at https://maps.googleapis.com/maps/api/js?v=3.exp&key=(my_browser_key)&signed_in=true&libraries=places:34 in hb
I've tried adding different 127.0.0.1 configurations into my Browser Key credentials that haven't worked, such as:
http://127.0.0.1:* , */127* , and */127.0.0.1:\d\d\d\d\d/*
That last one looks funny because every new run of my test suite generates 5 random digits after 127.0.0.1:, as seen in the error above.
*I don't want to ignore JS errors by changing my poltergeist config as mentioned in the error. With that said, I am NOT actually using the service on any of these acceptance tests. I don't want to test google functionality, I want to test the custom functionality surrounding these dropdowns.
Was able to circumnavigate this by setting the app_host and server_port directly into my Capybara config. Thanks to the accepted answer here. I added this to my spec_helper file:
def set_host(host)
default_url_options[:host] = host
Capybara.app_host = "http://" + host
end
RSpec.configure do |config|
config.before(:each) do
Capybara.current_driver = :poltergeist
Capybara.javascript_driver = :poltergeist
set_host("127.0.0.1:30111")
Capybara.server_port = 30111
end
end
Then I specified this exact server_port in my Google API key credentials. Acceptance tests now pass.
UPDATE:
It seems that Google's instructions are just out of date and incomplete (sigh). After more experimentation, simply 127.0.0.1 without any * or / does the job.
The above solution works as well.
I've been using the Google apiclient library in python for various Google Cloud APIs - mostly for Google Compute - with great success.
I want to start using the library to create and control the Google Logging mechanism offered by the Google Cloud Platform.
However, this is a beta version, and I can't find any real documentation or example on how to use the logging API.
All I was able to find are high-level descriptions such as:
https://developers.google.com/apis-explorer/#p/logging/v1beta3/
Can anyone provide a simple example on how to use apiclient for logging purposes?
for example creating a new log entry...
Thanks for the help
Shahar
I found this page:
https://developers.google.com/api-client-library/python/guide/logging
Which states you can do the following to set the log level:
import logging
logger = logging.getLogger()
logger.setLevel(logging.INFO)
However it doesn't seem to have any impact on the output which is always INFO for me.
I also tried setting httplib2 to debuglevel 4:
import httplib2
httplib2.debuglevel = 4
Yet I don't see any HTTP headers in the log :/
I know this question is old, but it is getting some attention, so I guess it might be worth answering to it, in case someone else comes here.
Stackdriver Logging Client Libraries for Google Cloud Platform are not in beta anymore, as they hit General Availability some time ago. The link I shared contains the most relevant documentation for installing and using them.
After running the command pip install --upgrade google-cloud-logging, you will be able to authenticate with your GCP account, and use the Client Libraries.
Using them is as easy as importing the library with a command such as from google.cloud import logging, then instantiate a new client (which you can use by default, or even pass the Project ID and Credentials explicitly) and finally work with Logs as you want.
You may also want to visit the official library documentation, where you will find all the details of how to use the library, which methods and classes are available, and how to do most of the things, with lots of self-explanatory examples, and even comparisons between the different alternatives on how to interact with Stackdriver Logging.
As a small example, let me also share a snippet of how to retrieve the five most recent logs which have status more sever than "warning":
# Import the Google Cloud Python client library
from google.cloud import logging
from google.cloud.logging import DESCENDING
# Instantiate a client
logging_client = logging.Client(project = <PROJECT_ID>)
# Set the filter to apply to the logs, this one retrieves GAE logs from the default service with a severity higher than "warning"
FILTER = 'resource.type:gae_app and resource.labels.module_id:default and severity>=WARNING'
i = 0
# List the entries in DESCENDING order and applying the FILTER
for entry in logging_client.list_entries(order_by=DESCENDING, filter_=FILTER): # API call
print('{} - Severity: {}'.format(entry.timestamp, entry.severity))
if (i >= 5):
break
i += 1
Bear in mind that this is just a simple example, and that many things can be achieved using the Logging Client Library, so you should refer to the official documentation pages that I shared in order to get a more deep understanding of how everything works.
However it doesn't seem to have any impact on the output which is
always INFO for me.
add a logging handler, e.g.:
formatter = logging.Formatter('%(asctime)s %(process)d %(levelname)s: %(message)s')
consoleHandler = logging.StreamHandler()
consoleHandler.setLevel(logging.DEBUG)
consoleHandler.setFormatter(formatter)
logger.addHandler(consoleHandler)
I was wondering if Wirecloud offers complete support for object storage with FI-WARE Testbed instead of Fi-lab. I have successfully integrated Wirecloud with Testbed and have developed a set of widgets that are able to upload/download files to specific containers in Fi-lab with success. However, the same widgets do not seem to work in Fi-lab, as i get an error 500 when trying to retrieve the auth tokens (also with the well known object-storage-test widget) containing the following response:
SyntaxError: Unexpected token
at Object.parse (native)
at create (/home/fiware/fi-ware-keystone-proxy/controllers/Token.js:343:25)
at callbacks (/home/fiware/fi-ware-keystone-proxy/node_modules/express/lib/router/index.js:164:37)
at param (/home/fiware/fi-ware-keystone-proxy/node_modules/express/lib/router/index.js:138:11)
at pass (/home/fiware/fi-ware-keystone-proxy/node_modules/express/lib/router/index.js:145:5)
at Router._dispatch (/home/fiware/fi-ware-keystone-proxy/node_modules/express/lib/router/index.js:173:5)
at Object.router (/home/fiware/fi-ware-keystone-proxy/node_modules/express/lib/router/index.js:33:10)
at next (/home/fiware/fi-ware-keystone-proxy/node_modules/express/node_modules/connect/lib/proto.js:195:15)
at Object.handle (/home/fiware/fi-ware-keystone-proxy/server.js:31:5)
at next (/home/fiware/fi-ware-keystone-proxy/node_modules/express/node_modules/connect/lib/proto.js:195:15)
I noticed that the token provided in the beggining (to start the transaction) is
token: Object
id: "%fiware_token%"
Any idea regarding what might have gone wrong?
The WireCloud instance available at FI-WARE's testbed is always the latest stable version while the FI-LAB instance is currently outdated, we're working on updating it as soon as possible. One of the things that changes between those versions is the Object Storage API, so sorry for the inconvenience as you will not be able to use widgets/operators using the Object Storage in both environments.
Anyway, the response you were obtaining seems to indicate the object storage instance you are accessing is not working properly, so you will need to send an email to one of the available mail lists for getting help (fiware-testbed-help or fiware-lab-help) telling what is happening to you (remember to include your account information as there are several object storage nodes and ones can be up and the others down).
Regarding the strange request body:
"token": {
id: "%fiware_token%"
}
This behaviour is normal, as the WireCloud client code has no direct access to the IdM token of the user. It's the WireCloud's proxy which replaces the %fiware_token% pattern with the correct value.