MobileFirst Command Line
Whilst GUIs are great and have become the "norm" for most people, inside and outside of IT, there are still some things that certain IT (system admins) prefer to do from the command line.
Mostly, these are repeated tasks that they can script or automate, passing parameter variables as needed. This means they can spend more of their valuable time scanning twitter or f**ebook or reddit (only kidding, they have much more valuable things to be spending their time on....like VR research!)
With this in mind the question comes up quite frequently: "can we script that?"
With MobileFirst Platform Server, you have the ability to run ANT scripts to manage deploying your runtime .war files into Liberty Profile and even WebSphere Application Server. This is usually fine for developers to run these tasks when they need to, but mostly they have no real idea of what is happening behind the scenes. All is great, if it all works fine. If for some reason you get a BUILD FAILED, error message then things start to get a bit tricky and you usually end up going the manual route to figure out at what part the ANT task is failing.
The above is great if you are just deploying the runtime .war file, but what about if you are now wanting to get more adventurous?
What if you now want to automate/script :
1. the deployment of the runtime .war file to WAS ND (as stated above, we can already do this)
2. the deployment of the .wlapp and the .adapters into the runtime .war file
3. the building of your project that creates the .apk or .ipa application (*subject of another future article)
4. the deployment of the .apk to the Application Center
#1 is covered by the following Infocenter: http://www-01.ibm.com/support/knowledgecenter/SSHS8R_7.1.0/com.ibm.worklight.appadmin.doc/admin/c_administering_ibm_worklight_applications_through_ant.html?lang=en
#2 is interesting as you can allow the developers to connect to /worklightconsole and manually select to upload the .wlapp and .adapters via their web browser.
#3 the approach to this can vary, but for instance, you could be using some form of DevOps mechanism (such as Jenkins) to checkout the code from your Source-control repository, build the code and output the build to a specific folder.
#4 once #3 has output the built version of the .apk or .ipa, you can either manually connect to /appcenterconsole and select to manually upload the file to make the application available within the Application Center.
For now, let's just cover the Command line instructions to achieve #2 and #4.
Each of these are covered within the InfoCenter - but unless you knew to look for them, you probably wouldn't know they existed. They are VERY powerful tools to know about and open up a lot of possibilities.
#2
http://www-01.ibm.com/support/knowledgecenter/SSHS8R_7.1.0/com.ibm.worklight.appadmin.doc/admin/c_administering_ibm_worklight_applications_through_command_line.html?lang=en
#4
http://www-01.ibm.com/support/knowledgecenter/SSHS8R_7.1.0/com.ibm.worklight.appadmin.doc/appcenter/c_command_line_tool_for_uploadin.html?lang=en
You have the option to continue to use ANT and build.xml configurations and the usage of this is explained very well in the sub-topics.
For the purposes of explanation I'm going to use the core programs themselves as an example of setting up and using both of these:
Deploying the .wlapp / .adapter files:
We will use the wladm program that is located within the MFP_install_dir/shortcuts/ folder.
To find out information about the applications deployed into a runtime, or to deploy an app into a runtime the commands you will need to know about are explained here.
To find out information about the adapters deployed into a runtime, or to deploy an adapter into a runtime the commands you will need to know about are explained here.
Then from the command line you can run the following to Upload a .apk file:
Okay, well, that seems to be all you need to know for now, about how to automate/script those tasks, at some point I'll wrap this up into a more formalised article about setting up DevOps (UrbanCode or Jenkins) that shows a complete end-to-end article on doing the whole Continuous Integration for WAS ND. For now, the above info should be enough to clarify what you need to do.
Mostly, these are repeated tasks that they can script or automate, passing parameter variables as needed. This means they can spend more of their valuable time scanning twitter or f**ebook or reddit (only kidding, they have much more valuable things to be spending their time on....like VR research!)
With this in mind the question comes up quite frequently: "can we script that?"
With MobileFirst Platform Server, you have the ability to run ANT scripts to manage deploying your runtime .war files into Liberty Profile and even WebSphere Application Server. This is usually fine for developers to run these tasks when they need to, but mostly they have no real idea of what is happening behind the scenes. All is great, if it all works fine. If for some reason you get a BUILD FAILED, error message then things start to get a bit tricky and you usually end up going the manual route to figure out at what part the ANT task is failing.
The above is great if you are just deploying the runtime .war file, but what about if you are now wanting to get more adventurous?
What if you now want to automate/script :
1. the deployment of the runtime .war file to WAS ND (as stated above, we can already do this)
2. the deployment of the .wlapp and the .adapters into the runtime .war file
3. the building of your project that creates the .apk or .ipa application (*subject of another future article)
4. the deployment of the .apk to the Application Center
#1 is covered by the following Infocenter: http://www-01.ibm.com/support/knowledgecenter/SSHS8R_7.1.0/com.ibm.worklight.appadmin.doc/admin/c_administering_ibm_worklight_applications_through_ant.html?lang=en
#2 is interesting as you can allow the developers to connect to /worklightconsole and manually select to upload the .wlapp and .adapters via their web browser.
#3 the approach to this can vary, but for instance, you could be using some form of DevOps mechanism (such as Jenkins) to checkout the code from your Source-control repository, build the code and output the build to a specific folder.
#4 once #3 has output the built version of the .apk or .ipa, you can either manually connect to /appcenterconsole and select to manually upload the file to make the application available within the Application Center.
For now, let's just cover the Command line instructions to achieve #2 and #4.
Each of these are covered within the InfoCenter - but unless you knew to look for them, you probably wouldn't know they existed. They are VERY powerful tools to know about and open up a lot of possibilities.
#2
http://www-01.ibm.com/support/knowledgecenter/SSHS8R_7.1.0/com.ibm.worklight.appadmin.doc/admin/c_administering_ibm_worklight_applications_through_command_line.html?lang=en
#4
http://www-01.ibm.com/support/knowledgecenter/SSHS8R_7.1.0/com.ibm.worklight.appadmin.doc/appcenter/c_command_line_tool_for_uploadin.html?lang=en
You have the option to continue to use ANT and build.xml configurations and the usage of this is explained very well in the sub-topics.
For the purposes of explanation I'm going to use the core programs themselves as an example of setting up and using both of these:
Deploying the .wlapp / .adapter files:
We will use the wladm program that is located within the MFP_install_dir/shortcuts/ folder.
To find out information about the applications deployed into a runtime, or to deploy an app into a runtime the commands you will need to know about are explained here.
To find out information about the adapters deployed into a runtime, or to deploy an adapter into a runtime the commands you will need to know about are explained here.
First of all, create a folder and extract the wladm file from the shortcuts
folder into it. Run the following command to make a file with the
following text:
$echo password=password01 > admpwd.txt
Then you can run commands like the following from the command line:
./wladm --url=http://<server-name>/worklightadmin
--user=admin --passwordfile=admpwd.txt --secure=false --verbose show
adapter --xml worklight Products
As explained in the Infocenter, the parameters from "show adapter..." are custom to what actions you want to perform. To deploy a locally made adapter to the worklight runtime, you would use:
deploy adapter worklight test01.adapter
We will use the applicationcenterdeploytool.jar program to manage uploading and deleting files from the Application Center.
The applicationcenterdeploytool.jar and json4j.jar files are located within the MFP_install_dir/ApplicationCenter/tools/ folder.
First of all, you will need to add the two .jar files to the CLASSPATH.
This is what I did on my Mac:
This is what I did on my Mac:
$export CLASSPATH=/Users/tony/../applicationcenterdeploytool.jar:/Users/tony/../json4j.jar
Then from the command line you can run the following to Upload a .apk file:
java com.ibm.appcenter.Upload -s http://<server-name>:<port> -c applicationcenter -u admin -p password01 -f AmazonApps-release.apk
This will then upload the specified .apk file to the
AppCenter. You can then go to the /appcenterconsole and see that the
.apk has been added. From the Android device, you can now start the AppCenter client app and you will see the Amazon app now available for you to download and use on your Android device.
If you wanted to upload multiple files you can just append the extra names at the end, such as:
app1.apk app2.apk app3.apk app4.apk
(*Yes, you are correct, the first method puts the password into a file for security reasons and the second does it straight from the command-line, I don't know why it's different. Raise a PMR or an RFE, if you want)
Okay, well, that seems to be all you need to know for now, about how to automate/script those tasks, at some point I'll wrap this up into a more formalised article about setting up DevOps (UrbanCode or Jenkins) that shows a complete end-to-end article on doing the whole Continuous Integration for WAS ND. For now, the above info should be enough to clarify what you need to do.
Comments
Post a Comment