[adrotate group=”3,4,7″]
We have had a number of comments about the new interface we developed for DR4i which is our Disaster Recovery solution for the IBM i and many asking when we will provide the same kind of monitoring interface for our RAP product.
We have been developing a new release of RAP which should be available in the 4th qtr of this year and took the opportunity to clean up the product and add the new apply technology we developed for the DR4i product. This gave us the ability to use the same PHP code on the new product as we developed for DR4i to show the apply processes. However the sending system status has to be collected as well, which requires additional code to complete. We did consider a couple of options to handle this with the data being pulled from both systems via PHP using sepearate EasyCom Server installs back to a single HTTP server, but after some deliberation we decided to use a new transport mechanism which is part of RAP to pull the data back to the target system before dispatching it to the PHP/HTTP server. This save on complexity and cost as you now only need a single HTTP or EasyCom server instance which is running on the target system.
The first changes we made were to add the status for the additional servers which already run on the source system, we had 2 servers for the object replication process and added a new server for the status distribution (This will also provide some level of synchronization from target to source when fully developed). Next we needed to show the object replication status and what the audit journal state was, we liked the splitting of the journals on DR4i so it was a fairly simple decision to add the Audit Journal in the same manner. Once we had this in place we just needed to add some additional data screens to show the information related to the monitors such as a list of profile and object replication errors plus any waiting object replication requests.
Here are the new screens so far. First is the sign on screen, because we have some Javascript functionality built in we needed to sense if it was going to work, the sign on screen now shows a warning if Javascript is disabled. An important design requirement is that anything which requires Javascript is not critical to the overall feel of the interface, as we are primarily using this as a monitoring interface we can ignore any buttons or screen displays which do not work when Javascript is disabled or provide alternative methods to complete the task.
Next we have the main display, you can now see the source servers and the object replication status all in one place, much better than having to use 2 systems and multiple screen to get the information!
If we have any profile errors you can get a list to see what they are, not a lot of data and pretty simple but it is not meant to be hard…
The last screen we developed was the object replication errors, this shows the details about the error plus any relevant information such as the command used or the path to the object.
We are still working on additional functionality but feel we are heading in the right direction, using EasyCom as the PHP i5_Toolkit server is definitely working out for us and it will be suggested to anyone who is going to run our PHP based interfaces. Next task will be to extract and show a list of the objects which are waiting replication.
If you would like to know more about the PHP EasyCom server or any of our products, please let us know and we will happily show you what we are doing.
Chris…