Sanity Test 101

Sanity testing is a simple test to check run through the system to ensure that the feature is deployed properly. The aim of sanity test is to probe for key known failure points from an activity such as migration, system upgrade or new enhancement deployment. The question is how should sanity test be conducted and what test coverage is sufficient.

Sanity Test Coverage

A good sanity test is a test that is quick and simple to determine if detailed testing is required. This test also provide confidence that the critical component of the application is working as expected. The sanity test is designed to cover a broad critical happy path of the application. E.g. if you are working on system upgrade, your sanity test needs to cover all the expected failure points due to upgrade rather than cherry picking of system modules or domains.

Automated Sanity Test

It is recommended to automate your sanity test if you are going to conduct sanity testing multiple times throughout the course of your system. For instance, system upgrade will require sanity testing at every upgrade. In addition, sanity test must be conducted within a day or two in order to decide if further testing can proceed. You will need to raise alarms when your sanity test takes more than two days. Thus, sanity test is usually automated for this reason

Sanity testing is a common activity for all major projects, upgrades or enhancements. The objective of sanity test is a fast and broad coverage of the functionality to be checked. Due to this reason, sanity test is becoming automated.

Upgrading Dilemma

During upgrading of system, you will be face with dilemma. This is mostly due to outdated support of system components or architectural changes. How should you handle the dilemma faced? Will this be showstopper to your upgrading project?

Preemptive Upgrades

System upgrades will create known issues and fixes. Experienced upgrading team is able to preemptively plan and check for known issues. These known issues should come with standard resolution approach and fix. This preemptive strategy is to fix as much as possible on these known issues. In the process, you will encounter dilemma on some known issues that cannot be fixed.

Waiting Dilemma

One of the worst upgrading dilemma is waiting dependency. It usually happens when multiple parties or teams are working on the upgrading project. Each team have a dependency task on another. Deadlock may even occur when teams are waiting for one another. This dilemma is detrimental and results in delays.

Key challenges for upgrading dilemma impacts scope and timeline. It is advisable to get experienced upgrading team who faces these dilemmas. Dependencies must be clear and be avoided at all cost. Expected results of dilemmas results in showstopper and delays in the projects. Do be aware and plan for upgrading dilemmas with the best approach.

Geothermal in Singapore?

There is an interesting news in Singapore lately on geothermal energy for sustainable energy. Looking at our geographic location, this sounds pretty far fetched. After all, Singapore only have a small “hot spring” at Sembawang. Moreover, there are no volcanic activities or hot spots underground. Is this a realistic choice of sustainable energy?

Low Carbon Options

Geothermal energy is a common choice of sustainable low carbon energy. They are usually build in regions with geothermal energy near to surfaces like hot spring. This give easy access to geothermal energy without drilling deep into the Earth’s crust. Geothermal energy is also renewable and remains part of the Earth system.

Why Impractical in Singapore?

Unlike other sustainable options, geothermal is shown to have reduced output with times. You will also need to build geothermal plant over your existing geothermal resources. There could also be byproducts from geothermal plants that require special attention to these toxic materials.

Geothermal power is a good source of sustainable low carbon energy. However, it is interesting to see how far the exploratory study on geothermal energy in Singapore. After all, the geographic location play a key role in harnessing geothermal power. With this aspect, Singapore does not seem to be a good fit for this option.

Upgrade or Migrate to Cloud

With strategic change of many software companies to cloud, organisations have two options for their aging applications. One, you have to upgrade to the latest version to extend their support life. Two, you migrate your application to cloud version. What will be your rational for these options?

Upgrading Rationale

Cloud based products differs from their counterparts because of the ease of customisation. The extent of customisation and your comfort level to risk will determine how much you will opt for upgrading options. However, the major risk continues to exist due to the end of support for your application. Upgrading options only help to extend time needed for your preparation to cloud.

Cloud Migration

Cloud migration should be the default choose because the end of support is real. Regardless of the option taken, the end game is cloud migration. However, cloud migration involves entire redesign of your architecture. There are also refactoring done to existing codes. The key difference with upgrading rationale is the higher risk. The risk includes the architectural changes and code changes that will impact your customised product.

The option to upgrade or migrate to cloud differs in the duration or risk management. The end point will remain as migration to cloud. Upgrading are able to provide you extra time to lower your risk to cloud.

Cloud Gateway 101

Cloud gateway is going to be a standard cloud architecture design for secure applications. There are many flavors of gateways but we will seek to understand some of the basic ones and why we need it for a secure and resilient architecture.

What are Gateways?

Cloud gateways are services that act as a bridge, control or connection between two or more distinct objects like applications, on premise and cloud. Gateway also acts as gatekeeper, throttle or insulation against healthy or malicious network traffic. In summary, gateway is another layer of protection to prevent your backend architecture from a complete meltdown if there are any vicious attacks in the Internet.

Gateway Type

These are some common gateways that you will likely adopt for your cloud architecture.

  • API gateway isolate, manage and controls the communication to your backend services and API calls like REST.
  • NAT gateway control and translates network traffic between different networks.
  • Storage gateway manage the storage from cloud to on premise storage.

Gateway is one of key components for designing of secure and resilient cloud architecture. Many cloud providers allows you to template and setup these gateways with default settings with ease. Thus, it is recommended that you must implement these gateways properly.

APEX REST Data Synchronisation to Local Table

Oracle APEX has an interesting feature to let you synchronise your external REST API to local database. This helps in caching and logic processing in your APEX. You can easily enable this feature without coding.

A Plus for APEX

The REST data synchronisation feature is a plus point for developers to use APEX. This is because it is common to consume or send processed data via REST API. Data replication for faster read access is also a useful feature. After learning about this feature, I find that it is very simple to enable data synchronisation.

Maintenance

It is not difficult to maintain this feature when the data can be cached to local database. You can also schedule refresh at different time interval. Majority of the configuration can be maintained via APEX page. It is important to take note of the following points for future maintenance.

  • Response JSON format
  • REST endpoints
  • Primary key
  • Field type
  • Parameters

If you are looking for an application for consuming multiple REST data sources. You can trial APEX data synchronisation. This feature is really useful to setup without additional coding.

Plan for Security Review

Security review is a common process for new application. It can be time consuming and when security and application cannot align focus on a common ground. These are some tips where application team can preempt and prepare for security review.

Design for Security

Often, application design focus on security requirements prior to go live. This can be detrimental when security team do not approved the architectural design because of security concerns. It is important to consider security design from day 1. Cloud security is one key area that is standard for all cloud deployments. Thus, the rule of thumb is to design security before you start your application development.

Iterate Security Review

Security review is an iterative process. Alignment with security expectations is important to secure the features. However, there are times where timeliness and cost outweighs the security request. You should iterate the security requirements and align on a common understanding. One such method is limit the exposure of your data in public subnet. Do note that it is not possible to clear security review in one setting. Thus, it is realistic to plan for security review process in your application development.

Security review is a common process for cloud development. This is because the notion of cloud is not within your own secured space. Therefore, you must include security design from the start of your project and plan for security review process. Getting the sign off from security team will lend confidence in your application.

Geolocation API

Geolocation API is becoming a standard default feature for many applications. This is due to the proliferation of mobile devices. Browsers also comes embedded with geolocation capabilities on laptop. There are still user considerations if you want to implement geolocation API for your application.

Relevance and Privacy

The implementation of geolocation API is subjected to privacy and relevance. For privacy, you can allow location access to the application. However, it is the control of users to provide this information. It is possible that you may not get the required location data. The relevance of location is as accurate as the timeliness of the data entry. Users may be updating the data at a different place from the intended location. If this is the case, location is no longer relevant.

The Future

Geolocation API is as reliable as the user permission and timely usage. You may query if geolocation API method can replace your mandatory user update of location. For the moment, this may not be the case. However, it will become a reality in future because getting connected will require your location data to provide the best choice of services.

Geolocation API is getting sophisticated and ubiquitous. There will come a time where this data is provided by default. While it is still subjected to user permission in the present, you can still consider enabling geolocation API approach to automate your location data collection.

Upgrading 123

Upgrading remains a major project for many on premise and legacy applications. It is really quite a pain and this is one reason why I favor Cloud platforms. In the meantime, I hope that I can do upgrading for the last time. These are some tips that the future may not be using for upgrading exercise.

Get the Right Team

The upgrading team is usually a separate team from the support team. This caused a disconnect with miscommunication and the need of knowledge transfer process. There are also instances where upgrading team miss out key components. After all, we suppose the upgrading team to be well versed in the new application. However, the team must involve a right mix of support team to understand the application landscape.

Agile and Systematic

Unfortunately, many upgrading projects follow waterfall model. I favor Agile and systematic approach. In all upgrading project, you need to be systematic in the changes you are doing. You must also be agile to adapt to new options of the upgraded components become a showstopper. Therefore, waterfall model is painfully slower and subjected to delta changes.

As long you are having legacy or on premise application, you will still be having upgrading nightmare. A move to Cloud will cut these costs and time as upgrades are done seamlessly backend. Hopefully, we will not suffer more upgrades in future.

ORDS REST POST Insert

ORDS (Oracle REST Data Services) REST is using POST for its INSERT SQL commands. You can setup ORDS POST insert quickly with these default settings.

The Setup

POST insert has a different configuration from GET. These are some of the settings to take note.

  • The source type must be PL/SQL.
  • Remember to set mime types to application/json.
  • It is important that you setup a PK (primary key) for the table to be inserted.

Reference source: ORDS POST Insert

Common Errors during Testing

You can use tools like Postman to do your API testing. These are the errors that will cause the API to fail.

  • Content-Type must be set to application/json.
  • Body format must be set to JSON.
  • Charset must be set to UTF-8.
  • Custom parameters name to exclude dash.
  • Missing PK in table.
  • Check your typos in the JSON payload.
  • Check your typos in PL/SQL.

ORDS POST insert will be easy to setup. However, you need to take note of the common errors. Hope this will help you to save several man hours in finding the issue.