Quali
OpenFire Real-Time Collaboration (Chat/Conference Rooms) Shell #1671
Quali-Community
started this conversation in
Integrations
Replies: 2 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
OpenFire Real-Time Collaboration (Chat/Conference Rooms) Shell
This custom service shell provides an integration between CloudShell and the OpenFire RealTime Collaboration (RTC) server whose details can be found @ https://www.igniterealtime.org/projects/openfire/
OpenFire uses the only widely adopted open protocol for instant messaging, XMPP (also called Jabber). At its core is the concept of a conference or chat room. The idea behind this integration is to allow a chat room to be created by this service for each sandbox. Messages can be entered directly into the chat room via a client such as Spark (for example, the Instant Messaging client @ https://www.igniterealtime.org/projects/spark/index.jsp) or via a command from this Shell.
Repository
README.md
Name
Open-Fire-Service-Shell
Owner
qarbondev
Type
2nd Gen Shell
Category
Other
Min. Compatible CloudShell Version
9.2
OpenFire Server Custom Service Shell
Introduction
This custom service shell provides an integration between CloudShell and the OpenFire RealTime Collaboration (RTC) server whose details can be found @ https://www.igniterealtime.org/projects/openfire/
OpenFire uses the only widely adopted open protocol for instant messaging, XMPP (also called Jabber). At its core is the concept of a conference or chat room. The idea behind this integration is to allow a chat room to be created by this service for each sandbox. Messages can be entered directly into the chat room via a client such as Spark (for example, the Instant Messaging client @ https://www.igniterealtime.org/projects/spark/index.jsp) or via a command from this Shell.
For details on functions provided by this shell, please see the "Operational Usage" section below.
CloudShell and OpenFire Compatibility
This service shell was developed and tested against CloudShell 9.2 GA. There is no reason why it would not work with 9.3 GA although it would require an update to the requirements.txt file as documented @ https://devguide.quali.com/orchestration/9.3.0/getting-started.html to reflect the use of a later version of the the cloudshell-orch-core package
The integration was developed and tested against OpenFire Server 4.4.1
Setup
The following steps should be taken when using this Shell:
Operational Usage
Adding Services to a blueprint
First, you need to add two instances of the service to a blueprint. Since service shells do not allow concurrent commands, this is necessary since one command needs to be running all the time - the one that monitors a chat room for messages entered outside of CloudShell in order to echo them in the sandbox.
We suggest you name the instances something like "Chat Room Monitor" and "Chat Room Service". Ensure that the properties are entered correctly into both services. Essentially, you need to identify the admin account and location of the OpenFire Server and also the same for CloudShell.
Reserving a blueprint and creating the chat room for the sandbox
Reserve your blueprint. Once Active, you should create a chatroom for the sandbox using the "Create Sandbox Chat Room" command. Notice in the Spark client and/or the OpenFire Server web GUI, there is now a new Group Chat room. The owner will be set as the admin user defined in the service properties for OpenFire. The members will reflect the permitted users of the sandbox. It is important that all users that need access to this chat room should be made Permitted Users including the current user.
It is also a good idea to invoke this shell command as part of the automated Setup process.
Start monitoring messages in the sandbox
In the other service instance (let us call it "Chat Room Monitor", click on the "Monitor Chat Room" command. This command will never terminate so simply leave it running. The purpose of this command is to ensure that any messages entered into the chat room outside of the CloudShell GUI are reflected in the Output window in order to keep all permitted users of the sandbox up-to-date. This code is based on the class MucBot in the driver code.
Sending a chat room message from CloudShell
Sending a message to the sandbox users is simple. Click on the "Chat Room Service" service and click on the command "Send Chat Room Message".
The message is echo'ed in CloudShell in the Output window, the monitor shows it again and you can see it directly in the Spark client for OpenFire.
Seeing messages entered directly into OpenFire via a Client such as Spark
Let us imagine that someone finds it more convenient to send a message via a client app such as Spark. In this case, you will see the message automatically picked up and reflected in CloudShell.
Broadcast message
OpenFire offers a simple broadcast facility that displays a pop-up window to all users connected via Spark or some other IM client. An example is shown below.
Listing all chat room messages to-date
To get completely up-to-date with all the dialogue that has taken place in the sandbox chat room, simply click on the command "List Chat Room Message History".
Attach chat room message history
To display and attach a simple text file of the message history to the sandbox, simply click on the command "Attach Chat Room Message History".
Deleting the chat room
To complete the cycle, you should delete the sandbox chat room when it is no longer required. Simply click on the command "Delete Sandbox Chat Room".
It is also a good idea to invoke this shell command as part of the automated Teardown process.
Suggested Improvements
If the sandbox name or any of its permitted users change, these are not automatically updated in the respective OpenFire chat room. An option to auto reflect such changes after a change should be offered perhaps.
Enhance the broadcast message command to reflect the message in all sandbox output windows not just the one the sender sent it from.
* Please allow 30-60 seconds for manual update changes to take effect.
Gary Wilson 10/09/2019 05:41 PM
· 4806 ·
Beta Was this translation helpful? Give feedback.
All reactions