This weekend, I wanted to add an additional field to the component occurrences in the CompHoundWeb database, which led me to discover and fix a trivial yet serious error in my C# client.
Also, let me mention a CORS workaround pointed out by my colleague Cyrille Fauvel and my night out to watch the lunar eclipse:
Did you notice that we had a total lunar eclipse early Monday morning?
I spent Sunday night on a hill with some friends celebrating a full moon fire, and then slept out beside the embers to catch it beginning around 4:50 in the morning:
Nice experience, this 'red moon', well worth while braving the cold.
Here is a way to quickly and easily temporarily work around a CORS issue.
CORS is a browser security measure that prevents you from running AJAX JavaScript code coming from different places and letting it interact together.
If such a situation arises and your server does not specifically authorize other domains via * = all or some other domain description method, you'll get a CORS issue.
Note that CORS, or cross-origin resource sharing, has to be enabled on the server side, whereas the security check happens on the client side. The Autodesk Apigee server is using ‘Allow-Control-Allow-Origin: *', so you should not get a problem, but it may happen still depending of the other domains or technology you're using.
Now and again a CORS issue might come up that requires time and research to fix, just when you are in a real hurry to get something else done and finished, e.g. for a Hackathon presentation.
In that case, the Allow-Control-Allow-Origin: * Chrome plugin may come in handy.
It is not a universal answer to this problem, but might enable a good quick workaround if you‘re in a rush.
Instead of spending hours (or days) to find out what is causing a CORS issue, you can install this little extension which intercepts the server response and adds the ‘Allow-Control-Allow-Origin: *' to the response header, telling your browser that all is fine. Then you can work on fixing the real underlying CORS cause later.
It is also useful if you have a piece of software that causes problems on a local server, but would work fine when you're online, e.g., swagger-ui from swagger.io.
Thank you, Cyrille, for pointing it out.
I added a field to the CompHound database to equip each component instance with a URN to identify the translated View and Data API model hosting it.
I thought that would be really quick and easy.
So it would have been, if the CompHound C# .NET Revit add-in had not been harbouring a pernicious little bug of my making.
Luckily, I deleted the mongolab database and started to rebuild it from scratch, which uncovered the flaw in the InstanceData implementation class.
I added the new urn field to the C# client and the node.js server, deleted the mongolab database, redeployed the server to heroku and reran CompHoundRvt in rst_advanced_sample_project.rvt.
When the Revit add-in was run, all data appeared to be transferred properly, yet nothing appeared in the database.
I suspected an error in the upsert function, since I had already had issues with that in the past.
I reimplemented a new version of it after looking more deeply at the mongo update documentation followed by how to update/upsert a document in Mongoose?
The new update4 method uses the mongoose findOneAndUpdate function:
update4 : function(req, res) {
var id = req.params.id;
console.log('Updating ' + id);
//console.log(req.body);
Instance.findOneAndUpdate({"_id":id}, req.body,
{upsert:true/*,new:true*/},
function (err, doc) {
if (err) return console.log(err);
//console.log(doc);
return res.sendStatus(202);
});
},
Still no data was being passed in, and the component instance documents only listed their _id and __v fields.
I read about Matt Schrager's RestSharp POST body problems and temporarily replaced request.AddBody by request.AddObject, but that did not help either.
Finally I logged the output of serialising the InstanceData to JSON and discovered that the result was empty right there at the beginning, in the C# client uploading it to the database via REST.
My InstanceData class was not exposing any public properties to serialise, so it never worked.
The FireRatingCloud sample that I based it on did it properly, though, so that works fine.
When I tested it last time, the database was already completely populated beforehand, so I never noticed that no new data was being passed in.
Every time I tested it in the past, it was just updating existing records with no changes.
Well, it is all fixed in the current CompHound implementation, in CompHoundWeb 0.0.19 and CompHoundRvt 2016.0.0.4.
All the links to Try it out Live have been appropriately updated to the new web server and mongolab database instances.