Welcome to volume 1 of a new blog series. SRP Tech Bites will be different from our normal tutorial oriented articles since it will provide readers with several smaller nuggets of potentially useful information. While these juicy morsels will mostly be oriented toward OpenInsight, we will expand your palette by including useful information from a wider range of technology topics. With the release of this inaugural edition of SRP Tech Bites, we extend an invitation to all of our readers to contribute their own delicacies. So don’t be shy…we are happy to share the limelight. Until next time, please enjoy a sampling from today’s menu…
We recently announced that we were quite busy porting our products to run in the OpenInsight 10 64-bit platform. For various reasons, it made sense for us to start working on SRP Utilities rather than any of our visual (i.e., ActiveX) products. At this time we are pleased to announce the general availability of SRP Utilities 2.0 for beta testing.
In case you missed it, 2017 has come and gone. We ended one of our busiest years on record and our workload does not appear to be slowing down. Our adventures involved several interesting projects, but the most fascinating commonality among them was the high demand for integration work. Three major enterprise clients introduced requirements to connect OpenInsight to SQL databases. Other projects had us building bridges to Microsoft Office applications via OLE Automation, writing interfaces to ESRI GIS solutions, and increased work with web services (much of this will be shared through upcoming blog articles). We are eagerly anticipating the journey ahead in 2018. To help you share in our excitement, we would like to provide a preview of various exciting developments within the company and within our labs.
In Part 1 of this article, we reviewed the types of error conditions that can occur in web APIs and the basic methods available for handing these situations. As previously noted, developers are not confined to handling errors in only one manner. In this article we’ll look at the advantages of each error handler and propose a few standard configurations for common situations. Developers can then use and adapt a configuration that best serves their needs.
Despite the claims of our previous and accidentally released article from last Sunday, this will be our first “how to” article related to the SRP HTTP Framework. We’ll look at the different methods and circumstances for handling errors in your web APIs. Part 1 will focus on the mechanics of error management within OECGI based web applications. In Part 2, we’ll consider best practice implementations of each error management option. Because the SRP HTTP Framework is based upon OECGI technology, the underlying communication layer between OEngineServer and OpenEngine remains the same. Therefore, most of this article will apply to both RESTful APIs created in our framework as well as traditional INET/O4W APIs created with the out of the box toolkit.
Early last year I posted an article advertising my 2016 Revelation User’s Conference presentation: RESTing before RevCon 2016. If you are unfamiliar with REST, then please take a moment to review this presentation preview and then return here. As noted in that blog post, and then reinforced at the conference, SRP has been using REST APIs as the bedrock of our mobile and web application projects. The goal of the presentation was to encourage developers to consider REST APIs as a way of adding value to their applications. Also, in keeping with SRP’s mission to enable and educate, we outlined the steps necessary to support RESTful URLs within an OpenInsight (OECGI) platform.
We hope you are enjoying our series on the SRP PreCompiler. Don’t worry, we’ll have more tasty goodness to serve you in just a few days. However, we wanted to take a quick detour and revisit our recent article on hooking, a technique that allows developers a way to intercept calls to stored procedures (including system stored procedures). If you are unfamiliar with this concept then please read our earlier article before proceeding. While the method we discussed has worked well for a very long time, it still leaves a footprint in the environment that is arguably intrusive. If this were only being done in a pure test environment that might be okay. But what if there is a need to add a hook within a mission critical production environment? Perhaps you want the hook to be temporary or only valid for your session. Even if it is only minimal, leaving behind permanent hooking routines bears some risk that something could go wrong and break the application. If only there was a way of hooking without resorting to renaming the original object record and replacing it with you own…