In addition to "Model Derivative", is there any tool provided to be installed locally on our desktop to convert models efficiently?
Or is there any plan to do it from autodesk forge side?
Unfortunately our Model Derivative service does not support local/on-premise deployment. Given the complex and resource demanding nature of this service technically it'd be extremely challenging for desktop grade systems to run efficiently.
There's no plan in the foreseeable future to support private deployment to any on-premise/third party platform either - again the technical complexity and licensing complications would be a major hindrance.
But that shouldn't stop you from coming up with your own locally hosted app to facilitate the translation - see our extractor sample here for inspiration.
Related
Anybody recommend any backends or frameworks for Forge?
I'm seeing resources for Nodejs, PHP, .Net Core and others which are for the backend.
Are any of these any more convenient or dependable with Forge than the others?
I also know Python and thought Django would be another option but I don't see too many resources on the Python side of things.
Any perspectives on the tools (pro or con) would be great.
The more I understand the kinds of tech stacks, user projects and ways people use Forge to expand on BIM 360 and other APIs the more it can help me and the community get familiar with the service.
This relies completely on the excisting stack used by your company. Forge is a collection of API's accessible via endpoints.
Any library just abstracts the calls away in a accesible way. I've had moderate succes with the dotnet core Forge package, it works very well but you are giving away some strict typing.
If you dont wanna be bound by abstractions made by other people, create your own ! This will ultimately lead to the most lightweight solution since you are only creating what you need.
Cheers
I have background in Inventor/Revit API development only, and need to learn enough JS to be able to work comfortably with the Forge APIs. I'll be booking myself into a JS training course to learn general skills, but what topics/modules must I definitely cover to have a solid foundation for Forge API development. I'll be working with BOM data, viewers and possibly web configurators.
Many thanks for your help.
We're a .Net shop that recently implemented the Forge Viewer for a client with Inventor Files. We built our service on top of Azure Functions and utilized as much .Net C# code as possible, as it is where we have the most experience and comfortability. The provided .Net SDK is very helpful: https://www.nuget.org/packages/Autodesk.Forge/.
The only API that you can't do entirely in .Net is the Viewer API. However, to get started I was able to use boilerplate code from the provided examples and get the models loading. From there I had our web developers get involved to handle the more extensive javascript programming for me.
Feel free to bounce any questions you may have off of me. We've just finished going down this road and it is very rewarding, but somewhat challenging at times for us .Net developers.
You need the JavaScript, as you already know. Take some time to improve security and OAuth authentication workflow. This sample includes most of it.
In most cases, you'll need a hybrid desktop app that can connect to the cloud, the image below (from the blog post) shows a generic approach for the architecture using Autodesk Forge (or any other cloud APIs).
I need to integrate an API created with .NET with SAP FI/CO.
Researching online I found out there used to be something called IDES that would provide access to an SAP server free of charge, just for testing purposes, but that's no longer available.
The Consolut solution seems to have been a viable solution while it was active:
https://www.outsystems.com/forums/discussion/6598/sap-server-test-account/
Anyway, my question is: Is there any way for an independent developer to test an SAP integration without spending money to access that server? Are there any options out there that would allow me to access an SAP instance for testing purposes?
Here you can find the official list of developer trials that you might access without having any kind of relationship with SAP:
https://www.sap.com/developer/trials-downloads.html.
If you have an SAP S-user, you might have access to more stuff from the SAP Marketplace. From my knowledge, IDES was / is only accessible through the SAP Marketplace (or external sources which use the marketplace themselves).
FI/CO runs on Netweaver AS ABAP (or an older alternative, e.g. R/3), so you could download it here: https://tools.eu1.hana.ondemand.com/#abap. But it will not have FI/CO in it. Based on the discussion here https://archive.sap.com/discussions/thread/2039981 I would say that it is not really possible to get FI/CO up and running on your local Netweaver.
This is a general strategy of SAP. They provide the possibility of trying out their technological platforms (HCP, HANA, NW, etc) but they don't really offer access to their business solutions for free.
If you don't find any other way of getting access to a FI/CO system (e.g. from a third party or customer) then maybe the best thing would be to use the local Netweaver and mock the FI/CO specific RFCs that you are using (assuming that you use NCo for the integration). At least this way, you would know that the integration works at a pure technical level (at some point though, you will need a real system).
Is SAP PI/PO now considered a true ESB? I've read various sources claiming it was not quite there 4-5 years ago.
And what if you have a very SAP-centric environment, would it be very strongly suggested to use PI/PO instead of the more standard integration platforms such as Mule ESB, Jboss Fuse, BizTalk and Oracle ESB?
If you primarily have expertise with the platform agnostic ESB's mentioned, would it still be worth integrating with SAP Pi? What are the advantages of PI?
I see they all have some option to integrate with SAP, but unbiased information seems hard to come by in the SAP-scene.
If your entire landscape consists of SAP modules then probably better to use PI.
If however you want to connect to other systems in the cloud, internally or externally then I would not choose PI.
PI is not an integration platform (better to use this phrase an an ESB). In this case it is better than have something fronting your SAP backend such as Biztalk, Fuse, Mule or other. They are more flexible and have more functionality when it comes to communicating with other systems and protocol. They are probably far easier to use as well.
Most of these integration platforms have commercial adapters that can connect to SAP. IBM's Integration Bus has SAP adapters, so does Fuse and others.
Like I said, it depends on your landscape and your integration requirements.
Today, as SAP NetWeaver 7.5 released, SAP PO is common ESB.
It is based entirely on Java8 and JEE5 standards, with optional old-fashioned ABAP usage.
Someone could implement integration scenarios with many tools (simple mappings, SOJO or EJB, or even your own JCA-adapter). Now SAP PO is really fast and reliable.
I'm just in the planning phase of developing my iPhone/iPad/Android app.
Basically the app will query data from remote data sources and store it locally. As data management will be the key feature of this app, so the UI isn't an important factory in this case. I decided to develop a HTML5 and JavaScript-based hybrid application and deploy it with PhoneGap/Cordova.
I'm a .NET developer, I use Visual Studio 11 for web development, so I found the Single Page Application template, which uses Upshot.js by default.
By exploring the alternatives, I've found JayData http://jaydata.org library. It seems to me that it's something similar to upshot.js.
Could you share your opinion, which way should I go to build a cross-platform HTML5 application?
Upshot and JayData looks similar but actually they are quite different, which makes your choice easier. There are things however both provides
Both has pros and cons (as everything in life)
Upshot.js is backed by Microsoft and focuses mainly on oData + Knockoutjs support. It is included in Visual Studio. You can query oData endpoints with it using a procedural query language.Upshot supports read/write operations, and also realtime updates.
JayData supports multiple datasources, among them are oData but also device local webSql as well, plus some other providers too. JayData let's you query oData or webSql on the same with, with sime JavaScript functions, so you dont have to learn sql and oData uri syntax. JayData provide read/write operations but realtime updates require a small user code.