Cloud and Mobile

Submitting a web service app to Autodesk App store

By Virupaksha Aithal

Click here to download the recorded session of “Submitting a web service ‘app’ to Autodesk App store” presented on 27^th of October 2016.

Links mentioned in the sessions

Submitting a web service to Autodesk App store http://usa.autodesk.com/adsk/servlet/item?siteID=123112&id=25479758

Submitting Fusion App to Autodesk App store http://usa.autodesk.com/adsk/servlet/item?siteID=123112&id=20149658

Autodesk App Store Developer Center http://usa.autodesk.com/adsk/servlet/index?siteID=123112&id=17183245

C# desktop with Data Management API

By Augusto Goncalves (@augustomaia)

This is a follow up from this previous post, which demonstrates a basic approach for desktop app with 3-legged OAuth. One of the biggest challenge is to ensure your client ID & secret are protected. 

For that, this sample has 3 projects:

1. Forge: a class library (.DLL) that wraps some endpoints for OAuth, Data Management API and OSS.
2. ServerOAuth: this is the ASP.NET server that stores the client ID & secret and implements the redirects and callback for 3-legged OAuth.
3. A360Sync: a WinForm (.EXE) desktop app that monitors a local folder and upload files to the respective A360 account.

Enough talking, let's see this sample in action:

The A360Sync project will call the ServerOAuth project to get the Authorize endpoint URL and redirect the end-user to the sign-in page. As the client ID is passed on the URL, it's not really hidden (e.g. a proxy server will see this URL with the client ID), but the desktop client don't expose it. As soon as the end-user types his/her password, it will callback the ServerOAuth, which calls GetToken endpoint with the client secret (which should not be shared under any circumstance). Now the ServerOAuth has the access token, so it redirects to a fake url that should trigger an error on the A360Sync desktop app webbrowser control and bingo: it can store the access token. As this handles only the user data, it's ok that the desktop app can see the access token (its access is limited to his/her data and there is no reason to hack his own data).

One concern: non-repudiation. As the access token is a permission to our app access the end-user data, if the same end-user uses this access token to modify its data, on the records, the data was performed by the application (as the 3-legged OAuth is a permission between Autodesk, developer/app & the end-user).

The source code is available on Github, but it should not be used on production just yet (still a work in progress), but I would love some feedback and will be improving it over the next few week. 

 

Forge Viewer - Issue displaying 2D models on Chrome for Mac v54

By Stephen Preston (@_stephenpreston)

Update October 26th 2016:

Our engineering team has now patched v2.10 and v2.11 of the viewer to address this issue. You may need to clear your browser cache, or if you store a local copy of the .js file you'll need to replace it with the newer version.

 

Our development team has detected that, as of version 54, Chrome for Mac is failing to render 2D models loaded by the Forge Viewer. The problem occurs with all viewer versions up to and including version 2.11. Our engineering team are currently investigating the best way to fix this issue - either as a patch to v2.11 or in our next incremental release (v2.12).

In the meantime, we have identified the following workarounds:

1. Don't upgrade to Chrome for Mac version 54 (all previous versions should work fine).
2. Resize the browser window. This will cause the viewer to refresh its view and the model graphics will appear.
3. Enter 'Full Screen' mode.

This issue only affects 2D views. 3D views should continue to work without problem.

Working seamlessly online/offline when developing your Web applications with the Forge Viewer

By Philippe Leefsma (@F3lipek)

    Whether you are a frequent traveler or not, if you are developing a Web application using the Forge Viewer chances are that at some point you may be interested in doing offline viewing, that is loading your models not from the Autodesk Cloud but from the local machine. I can see various advantages of doing that: the first one obviously is being able to develop and work on your app with no internet connection at all, but even if you do have a connection, you may enjoy faster loading time of your model when you have to repeatedly reload the scene to see your code modifications when working on a viewer plugin. Other customers may be interested in running a viewer application in a closed environment  or behind firewalls of their company with no http calls to the outside world. The offline approach applies to this type of requirement as well...

    My application is using the following technologies: NodeJS server, mongoDB database, RESTful API, React and ES6 for the building the frontend. The details I'm exposing here relate to that specific stack, however the concepts I am discussing in that post should easily apply to any other backend/frontend stack combination you may use on your side.

    Here is the general idea of the workflow: you first need to upload and translate the models you want to view offline. Typically when you develop your application, one or a few different models can be used for testing purpose, so you won't have to store locally all the designs your app is working with. Once you have your local models, they can be served as static resources by your server. You use the database to store information about each model, including a specific field that indicates if the model is local or Cloud-based. The bootstrapping JavaScript code that initializes the viewer will first look at the info in the database prior to load the model and either perform local or Cloud initialization. That way when using the local database in dev, models will be loaded from the local files and when your app is connected to the production database, models will be loaded from the Autodesk Cloud. All of that being transparent to the JavaScript code in your app.

    Here are the detailed steps you can follow to get that set up:

 1/ Upload your design to Autodesk Cloud and use the Model Derivatives API to generate the svf viewable format: see our Prepare a File for the Viewer step-by-step tutorial

 2/ Upon successful translation, download the design package locally. You can use the following npm package for that: view-and-data-npm. Even if it is still relying on the V1 API, it does the job. See the "Offline" section in the readme

 3/ Populate your mongoDB database with the correct records. In the case of my app, it is using a models collection with the following schema for each record:

 1 {
 2       "_id" : ObjectId("57efaf0377c8eb0a560ef467"),
 3       "urn" : "dXJuOmFkc2sub2JqZWN0czpvcy5vYmplY3Q6bGVlZnNtcC1mb3JnZS1kZXYvZW5naW5lLmR3Zg",
 4       "name" : "Engine",
 5       "path" : "resources/models/engine/0.svf",
 6       "env" : "Local",
 7       "options" : {
 8         //some app specific options
 9       },
10       "thumbnail" : "... base64 encoded thumbnail of the model ... "
11     }

     The path field has to point to the location of the .svf file in the static resources route server by your server

    the env field has to be set to Local for offline viewing and AutodeskProduction for Cloud-based viewing. That is the only field that is changed between my development  and production databases

 4/ You also need a complete local copy of the Viewer API files. There is more than the .css and .js you would reference in an online setup. The Viewer will dynamically fetch the extra scripts and resources needed once it gets loaded. It will look for those file relatively to the viewer3D.js or viewer3D.min.js that you loaded in your app, so if you keep the file hierarchy of the lib, things should be ok. You can find all the required files for the v 2.10 of the API in my project.

 5/ The rest of the job will be handled by the JavaScript code initializing your viewer application based on the env field set in the DB when loading a specific model. You will pass that value to Autodesk.Viewing.Initializer and let the viewer lib do the initialization. Below is the code that I'm using to seamlessly load a design offline or online. You can notice that in the offline case, we already know the viewable path that we want to load. In online case you need to first load all viewable path and select the one you want to load - in case your document has multiple views - my code here is simply loading the first viewable path, but you can tweak that based on your needs:

6/ I am using an .ejs template to generate my main html layout, this way when creating a dev build of my app, it will use the local viewer3D.js and when creating a prod build, it will reference the online version. The template is being generated by the webpack build, you can see my build config there.

    Having worked with the viewer API for a while now, I came to use that setup by refining my experience with those tools and I find it pretty convenient so far.

    The complete project applying all those concept is located at:
https://github.com/Autodesk-Forge/forge-rcdb.nodejs

Clash Detective from Navisworks to Forge Viewer

By Xiaodong Liang

 

Clash Detective is a typical workflow in BIM. Forge platform has not exposed such web service. While we can still combine Navisworks with the web application to coordinate the clash. With this idea, I wrote a small demo sample.

https://github.com/xiaodongliang/Forge-Navisworks-ClashTest 

By Clash Test .NET API of Navisworks, almost all information of clash test and clash result are achievable. The only challenge is: current .NET API does not provide the suitable viewpoint of the clash result like UI does. Although COM API provides ( InwOclTestResult.GetSuitableViewPoint), I do not want to iterate the clash results twice by .NET and COM separately. So the sample gets the ClashResult.Center and ClashResult.ViewBounds. The former is the center of the clash. The latter is bounding box including the area clashing and some surrounding context. Then the target of camera would be the center, and we can pick a suitable point on the box as the position of camera.  

 The source code of the sample also encloses the way of COM, just for reference. The Navisworks plugin also defines the structure of the clash data, and sends them to the web application.

With Forge Viewer, we can setup a management web application with viewable model, and ask the collaborators to coordinate the model easily. The web application provides the services for receiving the clash data and downloading the data. On the client side, a panel will display the clash test and result. The user can select the result. The corresponding viewpoint is switched and the clashed objects will be isolated.

In reality, it would be more useful to notify a new clash test is ready, and compare two clashes. I hope I could find time to improve it in the future.

Enjoy it :) 

New training on Autodesk Forge APIs: Six webinars now available for viewing

By Virupaksha Aithal

Whether you’re just starting out with Autodesk Forge or whether you want to learn more about a particular API, head on over to the Forge Playlist on You Tube where you’ll find a series of new webinars at the top of the list.  The training sessions not only explain and show what can be done with the Forge cloud services to connect design, engineering, visualization, collaboration, production and operation workflows, but they take you through the powerful cloud-based building blocks.  Pick and choose which API session you want to watch, or work your way through the series. 

Here’s the full list:

Introduction to Autodesk Forge and the Autodesk App Store

A brief Introduction to the Forge platform and the Autodesk App Store and the business opportunities they enable for developers/companies.

Introduction to OAuth and Data Management API

OAuth is the open standard used across the Forge Platform for token-based authentication and authorization. Learn more

The Data Management API provides a unified and consistent way to access data across A360, Fusion 360, and the Object Storage Service. Learn more 

Introduction to Model Derivative API

The Model Derivative API enables users to represent and share their designs in different formats, as well as to extract valuable metadata. (Its translation functionality was previously bundled as part of the “View and Data API”.) Learn more

Introduction to Viewer API

Viewer (formerly part of the “View and Data API”) is a WebGL-based, JavaScript library for 3D and 2D model rendering. 3D and 2D model data may come from a wide array of applications, such as AutoCAD, Fusion 360, Revit, and many more.  Learn more

Introduction to Design Automation API

Design Automation API, formerly known as the “AutoCAD I/O API”, provides the ability to run scripts on your design files, leveraging the scale of the Forge Platform to automate repetitive tasks.  Learn more

Introduction to BIM360

BIM 360 API allows developers to develop apps that integrate with the Autodesk BIM 360 platform to extend its capabilities in the construction ecosystem. Learn more

 

Introduction to Fusion 360 Client API

Introduction Autodesk® Fusion 360™, which is one of the first Cloud based mechanical design tools. It is an integrated CAD, CAM, and CAE tool for product development, built for the new ways products are designed and made.  Learn more.

 

If you have any questions, just drop us a line at [email protected]

 

3-legged OAuth on desktop apps (C# & WinForm)

By Augusto Goncalves (@augustomaia)

If you don't know OAuth or the differences between 2-legged or 3-legged authentication on Forge, please review this webinar.

It's quite straightforward to implement OAuth on a web app: as everything is on the browser, including the redirect callback, it's almost natural. What about a desktop application? In this case is not quite direct to handle callbacks or implement micro servers to handle it.

This code is almost an hack, but works for our purposes. Note this implementation is not safe, meaning your developer ID and secret can be easily hacked/read by almost any end-user. The safest way still to perform authorization on server-side. 

Let's use the System.Windows.Forms.WebBrowser, which works fine, but it doesn't handle error in the way we want for this sample. At the bottom of this post you'll find the full WebBrowser2 implementation copied from here.

Now on your app, create a form (assuming a WinForm application). Add a WebBrowser2 control, say wb. Prepare the Authorize URL (using your client ID, redirect URL and Scope) and navigate to this page. The end-user will be redirected to the Autodesk login page. When done, it will redirect to your callback URL, which is not possible or doesn't exist (at this sample, fake.com). This will throw a 404 error that we can capture. Voilà! Finally capture the code parameter of the query string and call the gettoken endpoint (e.g. using RestSharp) 

[PermissionSetAttribute(SecurityAction.Demand, Name = "FullTrust")]
public partial class oAuthForm : Form
{
  private const string FORGE_CLIENT_ID = "XxXxXxXxXx";
  private const string FORGE_CLIENT_SECRET = "XxXxXxXx";
  private const string FORGE_CALLBACK_URL = "http://fake.com/api/forge/callback/oauth";
  private const string FORGE_BASE_URL = "https://developer.api.autodesk.com";
  private const string FORGE_SCOPE = "data:read data:write data:create data:search bucket:create bucket:read bucket:update bucket:delete"; // assuming a full scope

  private WebBrowser2 wb = new WebBrowser2();

  public oAuthForm()
  {
    InitializeComponent();

    wb.Dock = DockStyle.Fill;
    wb.NavigateError += new WebBrowserNavigateErrorEventHandler(wb_NavigateError);
    Controls.Add(wb);

    // this is a basic code sample, quick & dirty way to get the Authentication string
    string authorizeURL = BASE_URL + string.Format(
        "/authentication/v1/authorize?response_type=code&client_id={0}&redirect_uri={1}&scope={2}", 
        FORGE_CLIENT_ID, FORGE_CALLBACK_URL, System.Net.WebUtility.UrlEncode(FORGE_SCOPE));
        
    // now let's open the Authorize page.
    wb.Navigate(authorizeUrl);
  }

  private void wb_NavigateError(
      object sender, WebBrowserNavigateErrorEventArgs e)
  {
    // This will track errors: we want to track the 404 when the login
    // page redirects to our callback URL, let's check if is the error
    // we're tracking.
    Uri callbackURL = new Uri(e.Url);
    if (e.Url.IndexOf(FORGE_CALLBACK_URL) == -1)
    {
      MessageBox.Show("Sorry, the authorization failed", "Error", MessageBoxButtons.OK, MessageBoxIcon.Error);
      return;
    }
       
    // extract the code
    var query = HttpUtility.ParseQueryString(callbackURL.Query);
    string code = query["code"];
    
    // now we have the code, let's make a Http call to 
    // /authentication/v1/gettoken 
    // and get the access_token...
    
    // you can use RestSharp for it, but I'll stop the sample here

    // you may want to close this form..
    this.Close();
  }
} 

Custom implementation of WebBrowser, let's call it WebBrowser2 (original post). Due our HTML/JavaScript implementation on the login page, some features are not natively supported by the WebBrowser (which, by default, have some features disables). To improve it, we need a set of registry keys (user level), which are well described at this stackoverflow answer. 

 

Using the Forge Viewer in a React Web Application

By Philippe Leefsma (@F3lipek)

    React - arguably the best front-end technology to built medium to large-sized web applications at the moment, says the JavaScript community. Unlike other tech out there from the JavaScript jungle, React is focusing only on the View part of the MVC pattern, bringing more flexibility to the developer choices. Components that you write in React and that you use in your app can be seen as interchangeable building blocks, a bit like what we intend to provide with the Forge Web API's. Well written components should be de-coupled from app main architecture and can be updated, rewritten, or replaced at no or small cost for the developer. In the current JavaScript ecosystem where things are evolving so quickly and new technology show up every other day, I definitely see that coming handy... Who wants to rewrite his entire application as your main framework is bumping major version? Not targeting any specific tech here ;)

    I was asked to write a demo web app to illustrate how to integrate seamlessly database information graphically with the Forge Viewer and decided to start on a clean base with a React application. The challenge when using React is to get your app architecture right because you have more choices to do and more moving parts. I knew I wanted to use Redux, to manage my app state, but that still leaves a great deal of choices to be made. After some research I stumbled accross that boiler plate: https://github.com/davezuko/react-redux-starter-kit. Over 6000 stars on github and recommended by Dan Abramov, creator of Redux - you can't go wrong with such references!

     I will post regularly my React tips, tricks and experiments as I go along with that project, but I wanted to start by showing how to use the Forge viewer in a React app. This post does not intent to be a tutorial on how to get started with React, you will find already so much resources on the web for that, so if you are not familiar with the technology, I recommend you spend an hour or two taking a look at the basics.

    The viewer is somehow different than - let's say - a classic web component because you can instantiate viewer3D object  only after the containing div has been appended to the DOM, so my code is using a little trick to reference that div from the component, see the render method. The rest of the code is pretty straightforward as far as the Viewer component is concerned. I tried to keep it as a strict minimum but provide methods to initialize the environment and load a document from its URN, so a maximum of control can be delegated to the controlling component while keeping the Viewer component flexible and easily reusable in any other project. But enough talking, here is the code of the Viewer React component in my app, links to the complete code on github and the live demo:

https://github.com/Autodesk-Forge/forge-rcdb.nodejs

https://forge-rcdb.autodesk.io

Here is a screenshot of the app featuring the Markup3D extension:

Viewer on Mobile using WebView [Xamarin]

By Augusto Goncalves  (@augustomaia)

Here is a recurrent question: can I use Forge Viewer on my mobile app? 

And the direct answer is: Yes you can, use a WebView!

What about a sample? Here you have it! For this really quick demo I'm using Xamarin cross-platform approach. It's actually quite nice: write in C#, compile and deploy on iOS, Android and Windows phones.

 

Next I'll prepare a more complete sample (with other Forge APIs), but for now just would like to share this piece first. 

You'll need this for setting up iOS permissions:

<key>NSAppTransportSecurity</key>
    <dict>
        <key>NSAllowsArbitraryLoads </key>
        <true/>
    </dict>

 

Introduction to BIM 360

By Virupaksha Aithal

Here is the recording of the “Introduction to BIM360” presented on 6^th of October 2016

 

Click here to download the presentation used.

BIM 360 documentation:

https://developer.autodesk.com/en/docs/bim360/v1

Blog on BIM 360 API & cloud-based technologies for AEC industry

https://fieldofviewblog.wordpress.com/

Forge DevCon recording on BIM 360

https://www.youtube.com/watch?v=cOQEyI-EMAQ