Technical

Deploy MCS Code from the Command Line

Deploying custom code to the Oracle Mobile Cloud Service can be a lesson in frustration. You have to download the scaffold, write your code, zip it up and then upload that using the Web UI. You quickly get into the flow of doing this, but if you need to check logs or look at any other screen in MCS you will have to re-navigate back to the implementation screen over and over again.

Turns out that the MCS team has created a command-line npm tool to help with. This may be obvious to some, but it’s not highlighted well enough in my opinion! So to help others with this issue, let me show you how we use it.

First download any of the MCS SDKs and the navigate on the command line to the mcs-deploy folder. Then simply run npm install -g to install the mcs-deploy programme into your path.

Now navigate to your MCS project and make sure you’ve filled out the toolsConfig.json file. At a minimum you want to add the baseUrl and authorization parameters (they will have placeholders initially). This should be easy enough to fill in, most of the parameters are in the settings page of your mobile backend.

With that done, to upload your code just run the following on your command line (from within the implementation code folder):

mcs-deploy toolsConfig.json -u <username> -p <password>

This programme will package up your code and send it to MCS using the REST APIs. You can optionally leave off the username and password details and it will ask you for those interactively. It would be great if mcs-deploy could read these from a configuration file (say ~/.mcs-deply, much like my equivalent deploy tool for Application Container Cloud). That way you could include the script in your build tools without having to hard-code or change credentials.

This has already saved me a heap of time!

If the MCS Devs are reading this, it would be great if the mcs-deploy code was a proper npm package. It would mean we could install this just using npm install -g mcs-deploy (without having to download the SDK). 

DevOps

Oracle Application Container Cloud – Ruby Support

The latest version of Oracle’s Application Development Platform was just released and with it bring’s Ruby support for Application Container Cloud Service! As a fan of ruby (scaffolding is the best!) this is great news. The ruby image comes from DockerHub, so in future we should hopefully receive a lot more languages.

Along with Java, Node, PHP, Python and now Ruby ACC is turning into a great polyglot development platform. I haven’t had a chance to play with it much, but once I get some of my ruby apps running I’ll post an update. In the meantime, here’s some screenshots to whet your appetite.

acc_ruby_1
Your current language choices
acc_ruby_2
The configuration for the container
Uncategorized

Oracle JET Lessons Learnt 1: Don’t enforce your coding standard

I’ve been playing with Oracle JET (and Oracle Mobile Cloud Service) to build a demo application for a customer (I’ll post on that later). I’ve learnt a few things along the way and I’ll post these under Lessons Learnt for all to share.

One of the issues I ran into whilst building my JET app is that I hate the coding standard the JET team seems to use. They like curly braces on a new line and I prefer them on the same line. Now this is normally just one of those vi vs emacs style debates, but after fixing the auto-generated main.js file to suit my style I ran into a problem. When I went to build my code for release (using grunt build:release --platform=ios) I got an error in the uglifyjs task (Unexpected token: punc ({).

Turns out the `//injector:mainReleasePaths` and `//endinjector` comments in the main.js file actually do something! The JET build process will insert the paths from your main-release-paths.json file between these two comments. If you fiddle with the location of the curly braces then the generated code will be invalid.

So lesson learnt: you can enforce your standard on JET, but watch out for injector comments in main.js!

Cloud

Abstract Cloud – Fog: Set up

In this series I’m going to show you how to use the Fog Cloud Abstraction Library to manage cloud services in code (or on the command line). Fog is a ruby library that allows you to interact with multiple cloud providers (AWS, Azure, Oracle etc) through code. It abstracts away the complexities of each providers APIs and authentication mechanisms and attempts to make it easier to deal with networks, servers etc.

In this post I’m going to take you through setting up Fog and getting a listing of servers in an Oracle Cloud account (the process for Azure, AWS etc is very similar).

Continue reading

Technical

Proxy Authentication in WebLogic

In our recent Label Security presentation we used a feature called Proxy Authentication. This allowed us to connect to the database as one user, but proxy the credentials of another so that we can access resources that proxied user can see. Without this we wouldn’t be able to use Label Security with our OSB services. It’s been brought to my attention that this is a useful feature that others would be interested in, but it’s hidden within my other post. So I’ve extracted the material out here to its own post so it can be found easier. Enjoy!

Continue reading

Technical

Cross Origin Resource Sharing (CORS) in OSB

So you’ve followed Oracle’s lead and started implementing REST services in Oracle Service Bus. But you very quickly run into a problem, how do I get my webpages to access these services via Ajax when they are hosted on different domains (or ports). This is generally forbidden in most browsers (as it violates the ‘same origin policy’, ie: you can only access resources in the same domain as you). The most common recommendation to resolve this issue is to enable CORS (Cross Origin Resource Sharing). Basically you just set a header in the response from the remote service that lists the domains that are allowed to request from this resource. If the web page is in that list the browser will allow the resource to be accessed.

Getting this to work in OSB is actually pretty easy and will mean that your OSB services don’t have to be on the same domain as your web pages. Read on to find out how.

Continue reading

Customer Success

ComSuper DVS Celeberation

Another customer success story and another amazing cake! Yesterday we celebrated the launch of the Document Verification Service at ComSuper. This was the first service delivered on ComSuper’s new Oracle Service Bus platform and is hopefully the first of many.

The DVS is managed by the Attorney-General’s Department and is one of the key initiatives of the Council of Australian Governments’ National Identity Security Strategy. ComSuper checks the information on identity credentials against the records of the issuing agency in real time to inform decisions that rely upon the confirmation of a person’s identity and is a key tool to eliminate use of fraudulent identities.

Continue reading