On my last SUP Notifications vs. Credentials – Part I, I wrote a little background on the Notification issues I faced while on a PoC project dealing with SUP Workflow.
Now I will show I would like to disclose the necessary steps I did to achieve what was intended.
I based this mini-how-to on the samples database, so I’ve created an MBO for table BONUS.
This is pretty much straight forward and you should be acquainted with the process of creating an MBO by now.
First thing is to create a Workflow Form for a Mobile Project after you’ve deployed the MBO to SUP.
The trick here is to let the Wizard do a little work for you. So before you finish creating the message driven WF, select the authentication option.
This will ensure that the starting points for authenticating a user gets created automatically.
After that, your WF should get the following components:
If we examine carefully the starting point and the Credential Request screen has two keys: cc_username & cc_password.
These will be used to store the credentials whenever an MBO is called. When prompted the user should enter their LDAP credentials (from OpenDS) here:
The WF client “knows” that these keys are to be used for SUP authentication because the input keys are assigned to be username/password.
This is done by means of setting the edit box’s advanced parameters as relevant for Credential Cache (username/password).
The following screen will help to understand better these settings if you need them to be entered manually:
I didn’t test if this works the way it is, but the official documentation states that this screen should be named ‘Credentials’.
So I simply renamed it to be:
If you enter just this piece of information, then when this WF runs the first time it will ask you to enter your credentials.
After it runs the first time, the screen will not open any longer. This will come in handy when the user’s password has been changed on LDAP.
For the whole solution this screen will never pop-up, because there will be another piece we need to put in place – so the Notification can work the first time around.
Trust me, it looks kind of odd, but this is the way to go.
To be able to start this WF from the mobile, we need a Client Initiated starting point. So let’s create one:
This screen will be our ‘Final Screen’ in the process of assigning an LDAP user to a particular device.
So we model this screen to have an exit button and an HTML view:
Assign a key to the HTML container and enter an HTML to state that the user’s credentials have been accepted and that the user should wait for WF Notifications via ‘Inbox’.
Pardon the ‘Portuguese’ text, but this was already captured.
The button should simply call the exit function, so the user has no other option than to get out of the application.
This means that the user will not be performing tasks initiated by him/herself. But this is required, otherwise the activation won’t work at all.
As I mentioned before, SUP will not assign a user to a device until an MBO operation is called and succeeds.
So what I’ve found out with the standard Business Suite WF is that we can ‘force’ an MBO function via Activation Starting Point.
This right here is the whole secret behind Notifications. By forcing the activation the first time around, we are able to enter user’s credentials and call an MBO.
This will ensure that the first time a WF is ran it gets the user assignment properly onto SUP.
Before we go into the details of the Activation Screen, your need a simple Server Initiated WF, so we’ll be able to send a Notification to the device via DCN-WF.
I’ve used the samples database for this and created an MBO for table ‘Bonus’.
The WF form should look like this once you created the ‘Bonus’ screens:
Now for the last part: The activation screen.
Add a “Activate” starting point and a new Screen to your form’s editor and connect them:
Now create a new screen named Success. This is the message we want to display the end-user when SUP has already assigned a user to the device.
The screen should have an HTML view and an Exit button:
Create a new key for the HTML view and assign to it an HTML stating that the Activation has been completed and the user should click on Exit button.
Another trick here is that this time, the exit button will not call the close function.
It will in fact perform a Submit by invoking the parent operation.
It is required to be this way, so we are able to call the MBO’s operation from the Activation screen.
Open the ‘Activation’ screen and create tree edit boxes, like this:
The first edit box doesn’t contain a label and is read only – primarily this is just to display instructions to the end-user.
The next two fields will be created the same way as the ‘Credentials Request’ screen.
Except, this time we will be using different key names so they don’t mix information with the other screen:
Add also a button named ‘Start Using’ and assign a Dummy operation to it.
I have created a dummy operation on my Bonus MBO of type OTHER and assigned to it a simple select statement.
This is how my MBO looks like:
After you assign the operation to the ‘Start Using’ menu, select the Communication Style so you can assign which screen should be opened after that operation is called.
The overall forms editor should be like this:
Even though we call the Success screen from the Activation screen by means of ‘Start Using’ button, we never call the Save method of the original screen.
This is why we need to set the Exit button to call the parent update. So when the user hits exit, the entered user credentials will be stored.
The Flow Sequence
If we look into SCC, this WF has not been assigned to anyone other than supAdmin.
After assigning the WF to a device, you should be able to run it.
The first time this WF is ran on a device the called starting point will be ‘Activate’ – since this WF has never ran before on the device.
The screen contains user credentials edit boxes, so we enter the LDAP user and password here and then click on ‘Start Using’:
The next screen is the ‘Success’ screen and will tell the end user to close the app.
In fact it will not close it, but rather save the entered credentials and start the normal WF operation – which would’ve been the ‘Client Initiated’ starting point:
Now the exit button will really close the application. And since it has already been supplied user’s credentials and they are safely stored, the ‘Credential Request’ starting point will never be called again – unless authentication fails in SUP.
Once the MBO’s dummy operation has been successfully performed, we will be able to ‘see’ the users assigned to a device on SCC:
User ‘supAdmin’ will always be mapped to all registered devices because we defined him on the MBO’s profile for authentication purposes.
This can be handy when we need to send a notification to all registered devices – no matter which user is working on them.
Here is another way to see which users are assigned to a device:
Now, all we need is to send a DCN-WF request to the user, and we will be able to see a message on the user’s inbox.