2. About Us
Matt White
– A Member of the London Developer Co-op
(londc.com) A group of UK based developers
– Domino web developer since 1996
– XPages developer since 2008
– Also…
• Owner at http://xpages101.net
• Lead Developer for Elguji Software
- IdeaJam
- IQJam
2
3. About Us
Mark Myers
– A Member of the London Developer Co-op
(londc.com) A group of UK based developers
– Developer from a support background
– 12+ years on Domino, 15+ years in IT
– Speaker at 4x Lotuspheres, 4x UKLUGs, 1x
ILUG, 1x BLUG
3
4. Software we’re using
IBM Domino® 9.0.1
IBM Domino® Designer 9.0.1
IBM Websphere® Application Server 8.0
IBM DB2® 10.1
MyEclipse® 2014 Blue Edition
4
5. Aim of this session
Surface an XPages application inside Connections
We’re assuming that you are Domino developers and that you know nothing about
developing applications for Connections
We’re going to show you three different ways to do this
This is from real world experience
5
6. What is Connections?
Not a single application server
Think a series of WAS applications, a database server and various add-ons.
It is not as simple as Domino development
But, it is not difficult to do. You just need to know the moving parts.
That’s what we’re going to show you today.
6
7. Our Development Environment
IBM Domino 9.0.1 running:
– HTTP – obviously as we are running XPages apps
– LDAP – our Domino server handles all authentication for IBM Connections
– Mail etc – all the usual add on tasks in Domino
IBM Domino Designer 9.0.1
Websphere Application Server
– Free download for developers of WAS 8.0 from: http://ibm.co/1dNp4Uw
• We use 8.0 vs 8.5 as Connections 4.0 & 4.5 only runs on 8.0
– You’ll also need to get the IBM Installation Manager v1.6.2
MyEclipse Blue Edition
– http://www.myeclipseide.com/blue/
Connections 4.5
7
8. Our Connections Development Environment
- Connections
Connections development is far simpler than connections installation and administration
Minimum of a Windows server with 8Gig of Ram and 30+ gig for a Empty installation
Installations files 14+ gig
https://bitly.com/18Ub03F (1115 slides not including the Domino installation for LDAP)
You CAN get it all working on one box, but it will be slow (fine for development but not really
suitable for users)
You can not use a WAS server set up for development as your connections box, all the
security needs to be turned on.
You will need a full day to do this!!
Connections settles in to about 10Gig of memory if left alone, so even on an 8Gig box you
will need to reboot every so often.
8
9. Our Connections Development Environment
Installing Connections 4.5 Crib sheet
– Install Domino and Enable LDAP (or use an existing one)
– Install db2 10.1 + Fixes
– Install WAS 8.0.0.5 + Fixes
– Create Connections DBs (with wizard)
– Install TDI
– Avoid Cognos ( you will rarely need it for development and it is optional )
– Link Domino LDAP with Connections ProfileDB with TDI (using wizard)
– Install Connections*
– Make a mental note to ask your admin to do it next time
9
*Discover at this point that you have
misconfigured some minor detail wrong (such
as the deployment profile) and spend hours
figuring out why and where
10. The Domino Application
Simple Approvals application
Three forms
Workflow around document status changes send update emails
10
12. What we’re going to show
Three different ways of surfacing the application in Connections:
1) Simple iWidget
2) Static HTML / JavaScript which integrates with an API
3) WAS Application which integrates with an API
Then as a bonus we’ll add some extra functionality
– Using the Social Business Toolkit we’ll post from the Domino application into other
Connections tools
12
13. Creating the iWidget
Very little to do, we already have a responsive web design
Bootstrap 3.0 will handle the scaling of the web page
We just need to configure the iWidget and deploy it
13
14. Creating the iWidget
We need to present it to Connections as a Open Social widget
The easiest way of doing this is with a simple domino page which we will call “approvals.xml”
14
15. Installing into Connections
You will need Connections admin rights.
When you log on to connections, click on the
“Administration” Link, on the left side bar under
“my Page”
15
16. Installing it into Connections
You can Add/Enable/Disable Widgets
from here
Click “Add another widget”
16
17. Installing it into Connections
First choose “Open Social Gadget”
Then “Trusted”
– Select “SSO” if you are logging
on with your domino credentials
and your admin has set SSO
up, this will enable your domino
security to work seamlessly in a
the widget
17
18. Installing it into Connections
Fill in other details (only Title and
Address are Mandatory)
Then Save and Enable the widget
18
21. Creating API – Server Settings
We need to enable the PUT and DELETE methods in
our website document on the Domino server
Discuss this with your friendly admin
– If not allowed, then process PUT and DELETE
using POST and an additional HTTP Header to
describe the actual method being used
• Ideally avoid this approach as it is non standard
for the rest of the world
22. We need to create an API
The second and third demos require an API so let’s quickly create one
The API will be a REST JSON service which allows us to read and write data programatically
It’s a simple process, but there a couple of gotchas
22
23. Creating API – Server Settings
We want to allow cross domain Ajax requests as
well
From the website document, create a new website
rule
Set the following fields:
– Type of Rule: HTTP Response Headers
– Incoming URL pattern: */api.xsp*
– Expires Header: Add Header if application did
not
– Custom Headers
• Access-Control-Allow-Origin: *
• Access-Control-Allow-Headers: Origin, XRequested-With, Content-Type, Accept
Restrict which domains can do this with the
Access-Control-Allow-Origin setting
Restart HTTP on your server
24. Creating API – Java Class
Now we can create the code in Domino Designer
First we’ll create a new Java Class called ApprovalsService
25. Creating API – Java Class
Now add java code, first the imports:
26. Creating API – Java Class
Add the renderService method
27. Creating API – Java Class
We’re going to support four methods using three functions:
– GET – renderServiceJSONGet
– POST – renderServiceJSONUpdate
– PUT – renderServiceJSONUpdate
– DELETE – renderServiceJSONDelete
URL Format is:
– …/mydb.nsf/api.xsp/[UNID]
28. Creating API – GET Method
The GET method returns JSON of views or a single document
32. Creating API – POST / PUT Method
JSON is sent to our service and based upon the method used to send it, we decide whether
to update an existing document or create a new document
– POST will try to update an existing document
– PUT will insert a new document
We use HTTP response codes to indicate success or any errors
– So 200 == Success
– 404 == document not found
– Etc.
– http://en.wikipedia.org/wiki/List_of_HTTP_status_codes
We’ll see how to call the service later on
35. Creating API – DELETE Method
A simple DELETE request is sent to our service and we can decide what to do with the
document.
– We don’t have to delete the document, we can simply move it out of live views
Again we use response codes to indicate success or failure
37. Creating API – API XPage
Now we create a new XPage called “api”
38. Creating API – API XPage
Make sure the XPage rendered property is set to false
Then in the afterRenderResponse event call the renderService method in our Java class
39. Testing the API
We use a Chrome plugin called “Dev HTTP Client”
– Free
– Download from Chrome Web Store
We need to control the URL, the METHOD, the HTTP HEADERS
We’re going to test
– Getting allrequests
– Getting myrequests
– Reading a document
– Updating a document
– Creating a document
– Deleting a document
39
48. Static HTML App
Now that we have an API, any number of external applications can access our original
XPages application
This is not limited to Connections of course
– Think Mobile!
We’re going to create a static HTML and JavaScript application which makes use of the API
and AJAX to perform some basic functions
The benefit of this is that we can build in error handling
– If the Domino server is down then we can display a useful error page for example
We might want to pull data from several different places
The iWidget may be too basic
48
49. Development Process
This is very simple
– We’re going to use a text editor!
We’ll also use some frameworks to make things nice and simple
– jQuery 2.0.3
• Will handle our Ajax requests etc
– Bootstrap 3
• Will be used for our UI
– Font Awesome
• Useful for general icons, in this case a spinner
Merge all the files into a folder in the following structure
– Root
• CSS
• Font
• JS
49
51. Static HTML Application
Then we’ll create a single JavaScript document, site.js
The URL will obviously need to be changed to match your environment
51
53. Static HTML Application
Once you have a working static HTML application, we’re going to want to deploy it to
Websphere Application Server (WAS)
We recommend using MyEclipse Blue for this rather than Rational Application Developer
– It’s cheaper
– It’s smaller and faster
– It’s much simpler
We need to create two different projects, one which will contain the code (war file) and one
which will handle hold and deploy the war file to WAS (ear file)
53
54. What are WAR and EAR files
A .War file (Web application ARchive) is a file used to distribute a collection of JavaServer
Pages, Java Servlets, Java classes, XML files, tag libraries, static Web pages (HTML and
related files) and other resources that together constitute a Web application.
An .Ear (Enterprise ARchive) is Basically a normal War file wrapped in a configuration
wrapper.
The Configuration wrapper of the Ear file contains features that while are very useful and
powerful for Websphere applications (adding JDBC connections on install etc etc) are
dangerous on connections server remember you are on a shared server and you can not
make any assumptions as to what is happening
– After working with multiple Connections administrators, the general opinion is to
document the features you require and ask your administrators to manually add them
rather than use the Ear file
54
55. Create EAR Project
In MyEclipse, select File -> New -> Enterprise Application Project
Populate the dialog:
– Enter Project Name
– Make sure Target Runtime is set to
Websphere 8.0
Click Next
55
56. Create EAR Project
In the next page of the wizard make sure to check “Generate application.xml deployment
descriptor”
Then click Finish
We end up with an empty project which we can
ignore for the moment
56
57. Create Web Project
Still in MyEclipse, create a new Web Project:
In the dialog enter the Project Name
Make sure that you choose to “Add project
to an EAR” and select the EAR project
we just created
Click Next
57
58. Create Web Project
Take the defaults on the next page of the dialog
Then click Next
In the final dialog window make sure that the
“Generate web.xml deployment descriptor” is
checked
Click Finish
58
59. You have seen most of this before
irectory
ource D
S
Root of Web
site
59
60. Import HTML into Web Project
In the WebRoot folder of the Web Project we just created, now import the HTML, JavaScript
and CSS files we created into the project:
Right click on the WebRoot folder and choose “Import”
60
61. Create approvals.xml file
In the same way that we created an XML for the deployment of the Domino widget, we need
to create a similar XML file for this project
Create a new XML file in the WebRoot folder called approvals.xml
61
62. Create approvals.xml file
Insert the following XML and save the file
Obviously adjust the href property to match your environment
62
63. Export EAR
Now that we have our (very simple) web project we want to get it deployed to our test WAS
installation to make sure it works
So we need to export an EAR file
Right click on the EAR project and choose Export
Choose “EAR File” from the list
Click Next
63
64. Export EAR
In the dialog choose the destination for the EAR file
Make sure to choose “Optimize for a specific server runtime” and choose Websphere 8.0”
from the list
Click Finish
64
65. Test Install WAS Application
We want to make sure that the WAS
application works OK
So open your browser
Now we want to open the WAS Admin
Console
Choose “New Application” from the
Applications menu
65
66. Install WAS Application
We now go through a 5 stage wizard to install the application
First we upload the EAR file we just created
Then click Next
66
67. Install WAS Application
Because this is the simplest possible deployment we can just take the defaults for the next
wizard pages
Choose Fast Path
Click Next
67
71. Install WAS Application
The next screen contains the install details with the final option to save the changes to the
server
Click “Save”
Now go to the Enterprise Applications list and
choose to start the application we just installed:
71
72. Test the WAS Application
Finally we can actually test the WAS application
The URL for the application will be the same server name as your WAS Admin console but
port 9080 (if you’ve setup with the defaults)
The application is called Connect14 and we want to open index.html
So in my case http://mattwhite2c8a:9080/Connect14/index.html
72
73. Deploy the WAS Application to Connections
Now we can deploy the app to
Connections
This is basically the same as the
deployment to Websphere that you
have just done for testing but with a few
subtle but important differences
A Connections instance already has
multiple applications and is nearly
always spread over multiple
servers/clusters to spread the load, you
must be careful your application does
not disturb this balance.
73
74. Deploy the WAS Application to Connections
To find out which applications are running on
which servers
– Select “Websphere application servers”
from the “Servers” left hand menu
– Select the server you want to check from
the list presented
74
75. Deploy the WAS Application to Connections
Select “Installed applications”
75
76. Deploy the WAS Application to Connections
You can now see all the applications running on the server and their startup order
76
77. Deploy the WAS Application to Connections
Once you have picked a suitable server (I prefer “InfraCluster” on my development
boxes as lots of small applications which are similar to most of the ones I develop)
– Install the application as you have done previously (using “Fast Path”)
– Select the server you want to deploy to, click the checkbox for your application
and click “Apply”
77
78. Deploy the WAS Application to Connections
You will see that the server name has now been updated
Continue on with the rest of the “fast track” as you have done previously
78
79. Deploy the WAS Application to Connections
A gotcha when deploying to
multi-server environments is
to remember which ports the
chosen server uses.
Return to the Application
server config for your chosen
server, and click on “Ports”
79
80. Deploy the WAS Application to Connections
If you are using the SSL port,
remember you will most likely be
using a self certificate on your
development box (these are
generated for you during the
profile creation section of the
connections installation)
The normal HTTP port (80)
The normal HTTPS port (443)
80
81. Deploy the WAS Application to Connections
The environment just shown is a default “medium” environment that is configured when
Connections is installed
– This is commonly considered the best environment for development as it simulates
a production environment but still works on a smaller local machine.
– You may be tempted to select the “small” installation option but it makes for a very
slow restart time for any application/server.
The missing element in what we are showing you verses a production Websphere
/Connections installation is the IBM High Availability HTTP server on the front end, this
is why we are putting port on the front of everything.
– It is invaluable for productions installations but unnecessary for development as it
adds an extra layer to deployments (you have to sync web modules between it and
Websphere when you deploy a new application) as well as taking up extra
resources.
81
82. Deploy the WAS Application to Connections
On a production server the application location decision will be taken by your
administrator, but you can provide help and advice
– It is more important to provide suspected load per user than you are used to for
Domino, include as much info as you can include processor and disk
requirements
On your development environment, you can cripple performance if you overload the
wrong server node which can lead to:
– Wasted time as you try to determine performance bottle necks
– Incorrect load requirements.
– Looking in the wrong logs for debugging (believe me it happens)
If you are running a large application you may not want to share a cluster/server at all
and may need a dedicated server/cluster.
If this happens on live you app may be incorrectly blamed for a system wide
slowdown
82
83. Deploy the WAS Application to Connections
Here it is side by side with the Domino one
83
85. Native WAS Application which integrates with an API
When you want to go beyond basic Connections integration or when you want to write a full
application on the connections platform you WILL end up writing a Websphere Application
Server Native App
– Native access to relation databases
– Strongly embedded Widgets i.e. homepage
– Strategic
We have built in features in Domino as it is an app development platform,
– WAS is an Enterprise App server, not a development platform
– Connections is Social Enterprise Software, not a development platform
Native Websphere apps have a great deal of power and although security can be tightly
controlled it is not as simple to implement as Domino
85
86. Native WAS Application which integrates with an API
For this example we are going to use a native application to pull from the Approvals Domino
database, and post it to the Connections stream
– We will do this on a schedule just as we would do with Agent Manager.
86
87. Integrating WAS into your IDE
With Native applications you will first want to build and test them locally on Websphere
– Far faster turn around
– Live console
– Your breakages don’t impact other people.
– Logs are much larger on a connections box
This can be done for Connections development unless:
– You are after the Connections backend databases and your administrator has restricted
access to them
• Administrators can often be persuaded to grant this access on dev boxes
– You are embedding widgets directly into customized Connections pages
• the security overrides needed are often more bother than they are worth
87
88. Integrating WAS into your IDE
To add the Websphere server to your
environment, in your IDE show the
“Servers” View
88
89. Integrating WAS into your IDE
Right Click and Select “Configure Server
Connector”
89
90. Integrating WAS into your IDE
Navigate to Websphere 8.0
Select the Websphere Home directory
– This will be the “AppServer” directory in
where ever you installed Websphere
too e.g.
“D:IBMWebsphereAppServer”*
*This is the Websphere data
directory so should not be installed
on a system drive. Also avoid spaces
in directories (WAS installer defaults
to “C:Program files”)
90
91. Integrating WAS into your IDE
Select “Load Profiles” to show the
profiles on the server, think of
profiles the same way as Domino
partitions.
Profiles each have their own HTTP
port and admin port
– the HTTP port will not default to
port 80
91
92. Integrating WAS into your IDE
You now have an entry in the server list
for each profile,
– You can Start/Stop and deploy your
applications to this profile directly
within the IDE
92
93. Integrating WAS into your IDE
You can also see the live console (SystemOut.log)
– this is stored in the IBMWebsphereAppServerprofiles<ProfileName>logsserver1
directory
93
94. Native WAS Application which integrates with an API
Our native app will consist of the following actions
Getting Environment variables (for service connections)
Fetching our REST data (from Domino)
Posting it to the Connections Activity Stream
Schedule these updates (like Agent Manager)
94
95. Native WAS Application which integrates with an API
WARNING: Teacher Moment
The will ALLWAYS be a better Way in Java, either a new tool or something you
don’t know about.
Our examples use the most exposed fashion way we can thing of, so you can see
what's going on
In real life you will use the best tools to make your job simpler.
Up till now IBM will have provided you with most of the tools you need
With J2EE unless you pick a full featured framework eg. SPRING
(http://spring.io/) , Vaadin (https://vaadin.com/home) you will have to pick your
own ‘best of breed’ tools.
95
96. Native WAS Application - Starting
First Build a new Ear and Web Project as per the previous Example
Note: We will be applying Jar libraries
manually, in this example, in real life you would
want to be using maven
(http://maven.apache.org/)
96
97. Native WAS Application - Getting environment variables
In Domino we take getCurrentDatabase() for granted.
Most other systems require a database connection which its self requires parameters
We want to be able to set these parameters with NO HARDCODING
Thankfully Websphere allows application specific variables
97
98. Native WAS Application - Getting environment variables
These are stored in the application “Deployment descriptor” or
web.xml
This is a XML configuration file that is used to store artifacts
that are used in a Java application.
It controls many functions for your applications including
Servlets and URL Paths
The Welcome File List
Error Handlers
Recourses
98
99. Native WAS Application - Getting environment variables
First add the variables to the Web.xml including default values
<env-entry>
<env-entry-name>RESTusername</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>restadmin</env-entry-value>
</env-entry>
<env-entry>
<env-entry-name>RESTpassword</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>password123</env-entry-value>
</env-entry>
99
100. Native WAS Application - Getting environment variables
On a deployed application
you can see and edit the
Environment variables from
the properties of deployed
applications
100
101. Native WAS Application - Getting environment variables
This can enable your admin to keep production passwords away from developers
or simply not hardcode things
101
102. Native WAS Application - Getting environment variables
There are multiple ways to access the variables, we are just doing to use the simplest,
which is to pick them up off the “initialContext”
initCtx = new InitialContext();
String rESTurl = (String) initCtx.lookup("java:comp/env/RESTurl");
Ensure that you use the full name so “Java:/comp/env” + the name you gave them
A more advanced way is with the @Resource annotation
See http://en.wikipedia.org/wiki/Java_annotation &
http://docs.oracle.com/javase/tutorial/java/annotations/basics.html for annotations
background
102
103. Native WAS Application - Getting environment variables
Here we are just picking them all
up
103
104. Native WAS Application - Fetching Domino Data
Now that we don’t have to hardcode variables we can go get the Data from the Domino
API we have written previously.
Go to https://code.google.com/p/google-gson/ ,download the “google-gson-2.2.4release.zip”, and extract it
104
105. Native WAS Application - Fetching Domino Data
Select the “Lib” directory in
“WEB-INF”, right click and
select “Import” “File System”
105
107. Native WAS Application - Fetching Dominio Data
We are going to fetch the JSON Data from Domino and parse it into a Java class so that
it is easy to work with
As we can’t be bothered to manually convert the JSON data to a POJO* we will use
http://www.jsonschema2pojo.org/
107
108. Native WAS Application - Fetching Dominio Data
Select “JSON” and
use some of the data
from the testing with
the DEV HTTP
Client
Selecting the Lowest
common
Denominator here
108
109. Native WAS Application - Fetching Domino Data
Gives us this Class which we can use
109
110. Native WAS Application - Fetching Domino Data
As we are going to use this class for
converting from JSON add
“@XmlRootElement” just above the
class name
110
112. Native WAS Application - Posting to Connections
Now that we have a List of Request Objects, lets send some of their details to the
Connections Activity Stream.
Go to http://abdera.apache.org/ ,download the zip, and extract it
Get the Main Jar
112
113. Native WAS Application - Posting to Connections
Lots and lots of supporting Jar files.
You don’t need them all depending
which of the Abdera functions you use.
This is also a perfect example of what
can lead to “jar hell”.
Note: Once you happy with ATOM in
general and are only doing Integration
with connections, switch to the Social
Business Toolkit
(https://www.ibmdw.net/social)
113
114. Native WAS Application - Posting to Connections
Select the “lib” directory in
“WEB-INF”, right click and
select “Import” “File System”
114
115. Native WAS Application - Posting to Connections
Find and select the Abdera Jar and
import it
Repeat the process for the supporting
Jar files in the lib folder
115
116. Native WAS Application - Posting to Connections
Jar files added to this project are automatically
on the build path i.e.
Go to the Project Properties
Select “Java Build Path”, go to the
“libraries”
You can see the files are already on the
build path
116
117. Native WAS Application - Posting to Connections
First let’s write a function that can take one of the Request objects we have converted
our Domino JSON data to and send it to Connections
117
120. Native WAS Application - Posting to Connections
Now let’s write some code to hold it all together
120
121. Native WAS Application - Posting to Connections
That’s all well and good but how are these functions called in the first place?
What we really need is something like Domino Agent Manager but for a
Websphere app
121
122. Native WAS Application - Scheduled Updates
Go to http://quartz-scheduler.org/ ,download the Jars, and extract them
122
123. Native WAS Application - Scheduled Updates
Select the “Lib” directory in
“WEB-INF”, right click and
select “Import” “File System”
123
125. Native WAS Application - Scheduled Updates
Quartz uses an Event Listener
http://docs.oracle.com/cd/E15051_01/wls/docs103/webapp/app_events.html#wp178122
We have to add that listener to the Web.xml file
125
126. Native WAS Application - Scheduled Updates
<context-param>
Quartz Listener and
Basic Parameters for
Web.xml
Which gives things like
the location of the
Quartz properties file
<param-name>quartz:config-file</param-name>
<param-value>/quartz.properties</param-value>
</context-param>
<context-param>
<param-name>quartz:shutdown-on-unload</param-name>
<param-value>true</param-value>
</context-param>
<context-param>
<param-name>quartz:wait-on-shutdown</param-name>
<param-value>false</param-value>
</context-param>
<context-param>
126
<param-name>quartz:start-scheduler-on-load</param-name>
127. Native WAS Application - Scheduled Updates
Next we will create the quartz.properties
file in the “WebRoot” “WEB-INF”
“classes”
127
129. Native WAS Application - Scheduled Updates
Now we want a servlet
for the quartz scheduler
“agent manager” to run
in.
Open up the web.xml file
and add the
configuration for a
servlet
129
130. Native WAS Application - Scheduled Updates
<servlet>
Add the following to the WEB.XML
<servlet-name>QuartzInitializer</servlet-name>
<servlet-class>
The “<load-on-startup>2</load-onstartup>” means that this servlet starts
com.connect2014.ScheduledAgentStarter
when the application starts and triggers
</servlet-class>
the class “init”
You can see the class name that we
need to create next in the “<servletclass>” parameter.
<init-param>
<param-name>shutdown-on-unload</param-name>
<param-value>true</param-value>
</init-param>
130
<load-on-startup>2</load-on-startup>
131. Native WAS Application - Scheduled Updates
That’s the equivalent to “Agent Manager” set up, now lets do a “Scheduled
Agent”, a chunk of code that will start when the web app starts.
First let’s build our base agent by creating a new Class and getting the default
quartzScheduler
131
134. Native WAS Application - Scheduled Updates
As you can see the class we created on the last slide extends “HttpServlet” and
contains “init”
That means that when the servlet we added to the web.xml starts (when the
application starts), it will run the “init” and we can start scheduling
134
135. Native WAS Application - Scheduled Updates
Inside the init function of your
schedule we now define:
1)A new job (linked to our Class)
1
2)A schedule
3)Link the Job and schedule
together
4)Trigger the scheduler i.e. “load
Agent manager”
135
2
3
4
136. Native WAS Application - Scheduled Updates
– While we are here this is a Crontrigger
•
http://quartz-scheduler.org/documentation/quartz-2.2.x/tutorials/tutorial-lesson-06
– Very very powerful, but sometimes overly complex
•
If you need a simpler version, check out “Simple Triggers”
•
136
http://quartz-scheduler.org/documentation/quartz-2.2.x/tutorials/tutorial-lesson-05
137. Native WAS Application - Scheduled Updates
Also we need to send all the
environmental parameters we
built before, into the new “Job” we
have just created
137
138. Native WAS Application - Scheduled Updates
To enable our existing class to be used as a Job, is has to have “implements Job”
And it must possess the “execute” method
138
139. Native WAS Application - Scheduled Updates
Finally we can now add the code we wrote before to this function as well as pickup all the
variables
139
140. Native WAS Application – Build and Deploy Application
Build the Ear file and deploy the application as per previous native application example
140
141. Native WAS Application
Once the Application
Starts, it pumps
entries to the Actor
user’s* activity stream
from the domino rest
service
*(the one who's credentials
are supplied)
141
143. Recommendations and Further Reading
As already mentioned neither Connections nor its host, Websphere, are application
development platforms in the way Domino is.
– You will need to bring your own toolbox of libraries and toolkits to perform many of the
functions that you have taken for granted with Domino
143
144. Further reading
When you need: Agent Manager
We Recommend: Quartz (http://quartz-scheduler.org/)
Alternative: java.util.Timer
– Simpler but not as powerful
– Example: http://www.mkyong.com/java/jdk-timer-scheduler-example/
144
145. Further reading
When you need: To connect to a Relational Databases (such as the Native Connections
Dbs)
We Recommend: Hibernate using JPA
When we moved from Domino to Connections we went from the easy going world of NOSQL
and constantly being in a database context to Relational databases and defining our own
contexts (most likely DB2)
There are lots of fighting over if you should use a ORM (Object-relational mapping)
framework such as JPA or direct SQL, but frankly, its quick, reliable and does not give you
grief
See Slide deck on SHOW104
145
146. Further reading
When you need: Make your data accessible as Json
We Recommend: gson https://code.google.com/p/google-gson
Alternatives: Jboss Resteasy (http://www.jboss.org/resteasy) & Jersey
(https://jersey.java.net)
146
147. Further reading – ATOM (Connections feeds)
When you need: Talk to Connections (ATOM)
We Recommend: Abdera (http://abdera.apache.org/)
147
148. Further reading - Email
When you need: Send an Email
We Recommend: https://javamail.java.net/nonav/docs/api/
Get the SMTP server details off your admin as they will
already be setup for connections (it was in the notifications
part of the Connections setup)
148
149. Further reading - Email
Properties props = new Properties();
props.put("mail.smtp.host", "my-mail-server");
Session session = Session.getInstance(props, null);
try {
MimeMessage msg = new MimeMessage(session);
msg.setFrom(“sender@ldc.com");
msg.setRecipients(Message.RecipientType.TO, "you@example.com");
msg.setSubject("JavaMail hello world example");
msg.setSentDate(new Date());
149
msg.setText("Hello, world!n");
150. Further reading – Homework
If you think you have a handle on all of this, your next stops
to be a “Proper” Java Developer are
– Maven build management (http://maven.apache.org/)
– Source Control - Git/Github (http://git-scm.com/ &
https://github.com/)
– Continuous integration - Jenkins (http://jenkins-ci.org/)
– A Web framework (Spring http://spring.io/ , Grails,
Vaadin https://vaadin.com/ , GWT, Wicket, Play, Struts
and JSF)
– Spring Annotations to make use of modern Java and
reduce the amount of code you have to write
150
151. Access Connect Online to complete your session surveys using any:
– Web or mobile browser
– Connect Online kiosk onsite
151