The user interface generator handles on screen presentation of the user objects for each of the <<ui_change>> actions in the activity diagram, while the <<command>> actions represent code that must be written to fetch data from some system. This could be code to call MDM Server transactions and, since the user interface generator is provided with MDM Server, this code can also be generated to create a basic sample data maintenance user interface. There’s no technical reason to prevent the commands getting data using any web services, or direct from a database, or anywhere really. To test drive a UI, there’s an option to generate all the code necessary for a simple file based data store for example.
If you’re interested in finding out more about user modelling and the user interface generator, there’s an article on developerWorks. and some related blog posts. I’ve also blogged here about user modelling in the past.
Any questions or comments would be very welcome indeed.
This post is just a few hints to get you started customising a maintenance UI generated for an MIH addition.
The user model generated in the previous post does not contain any diagrams. You can navigate and manipulate the model directly in the Project Explorer view but it is useful to have diagrams to show different aspects of the user model which you’re interested in, or when making modifications. There are a couple of quick ways to get UML diagrams depending on what you need them for.
…which leads neatly on to creating a domain for these user tasks.
The default user model does not include any domains, so when you initially log in you always have to switch to the goal view. One of Iain Duncan’s MDM Workbench blog posts explains how you can modify a generated user interface to only display the goal navigation method. To avoid making any code changes to the generated user interface, I’m going to create a new User Domain, so you can use both navigation methods instead. This approach would probably be more useful if your maintenance UI covers multiple modules.
Click on User Domain in the User Model section of the model palette, as shown below, and add it to the diagram.
Use the Generate User Interface transformation configuration to regenerate the user interface; open the Generate User Interface.tc file and press the Run button on the Main tab. You can also use the context menu option to run the transformation, which is under Transform when you right click on the Generate User Interface.tc file.
Republish the web application and log in to see the new domain. You’ll notice that there are only two user tasks under the SocialBookmarkServices domain. This is because the addBookmark task appears in the user model as a non navigable supporting task for the Query Data goal. We’ll fix that in the next section.
To get the addBookmark task to appear in the domain navigation you could just set the isNavigable property to True on the supporting task stereotype. Instead, I’m going to go further and create a new User Goal for adding data.
Regenerate and republish the web application and you should now see all three tasks in the domain navigation, plus a new goal in the goal navigation. Those task names don’t look all that friendly though but we change improve them very easily.
The default task names are based on names from the module model, which may be obscure for someone using the maintenance UI. The task names aren’t actually too bad for the bookmark example but I would still prefer something a little less internal looking. The names on the UI are fully translatable using properties files in the UI’s help project, which makes it very easy to give them sensible names without needing to modify the generated user model.
These are just a few ideas to get you started. If you change anything in the generated user model, make sure you remove the generated stereotype, otherwise your change may be lost if you regenerate the user model.
The maintenance UI looks slightly better after the modifications above, but it would be a bit easier to use if the SocialBookmarkServices model had some transactions that worked without knowing the primary key of all the bookmarks. Changing that will require some custom code in the MIH module as well as user model modifications, which should be enough for another post!
This is the second in a series of posts introducing Master Information Hub (MIH) development using the MIH Workbench. This time you’ll see how quick and easy it is to extend MIH and create a maintenance UI for your new domain, with no coding required. If you want to try this exercise yourself, make sure you have set up the development environment first. The sample I’ll be building is based on social bookmarking, but you could build any data model you like.
To begin, create a new Hub Module Project to work on your data model. Open the File menu and choose New > Project…, then look for InfoSphere Master Information Hub > Hub Module Project.
You should now have a new project containing an empty module model, which will be opened in the module editor. Switch to the SocialBookmarkServices editor’s Model page; this is where you will enter the data model for the new module. To start with, add a new entity and add a few simple attributes as follows.
Note: when running in the test environment, the server will have the contents of the CustomerResources project on its classpath, but to deploy an application on a production server, the properties.jar and DWLSchema.jar files in the MIH EAR need to be manually updated with the contents of the CustomerResources project.
Now the extended MIH application is ready to publish and use. If you followed the instructions in step 4 of the getting started post, you can right click on your server in the Servers view and choose Publish.
Click finish and wait for code generation to complete. Now for the fun bit!
One of the new features in the latest workbench is the ability to automatically generate a basic maintenance user interface. This uses information from module models in the client project to create a UML user model for the User Interface Generator. Even the command beans are taken care of automatically when the user interface is generated, connecting to your MIH application using the web service client. As before, open the File menu and choose New > Project…. This time you need InfoSphere Master Information Hub > Hub User Interface Project. Again, I’ve based the project name on the hub base name. Enter a Java package name for the generated code, and pick the target runtime you’re using. Click finish and wait for code generation to complete.
That’s all there is to it; deploy the generated web application to the same server as the MIH application using RSA. If you followed the same example, and your test server is using the default ports, you can open the maintenance UI using the following address.
Note: if your server is using a different port, you will need to update the service URLs used by the web service client. These are defined by the ejbModule/client.properties file in the web service client project.
The generated user interface should provide a simple starting point for maintaining data in a custom MIH application, and it’s a great tool for development and demo purposes. In future posts I hope to show some simple ways you might want to alter the generated user model to customise this maintenance UI.
A web 2.0 skeptical geek all rounder planning to write about technology, politics, growing vegetables, board games and walking.
Off to a flying start with some great home automation with arduino, Home Easy, MQTT and a helping of hackery.
Definite technology slant with an enjoyable hint of grumpy old man which I’m definitely hoping will continue!
Some really varied arduino projects in addition to home automation and tweeting cats. While the only circuit I’ve cobbled together recently is sitting in an ice cream tub in the porch, Mike is a master at packaging projects- his scalextric race timer is a work of art!
Not as easy to sum up given the number of posts but a distinct focus on technology of various kinds. Probably need to run it through wordle to get a better idea!
The trouble with making lists like this is that I am bound to have missed a few! I’ll just sneakily add more if I have… which reminds me, I was going to make more of an effort with a blogroll at some point soon.
First from the Mix and Mash Blog, and giving this post its title, Pic and Mix project from Kent County Council: I wonder if Eastleigh do anything similar.
From John’s Random Musings, Exposing your WebSphere logs as ATOM feeds: definitely want to give this a try with MDM Server.
From knolleary.net, Twitterlogue: wish twitter had been around when I was in New Zealand. Brilliant.
From developerWorks, Leverage DataPower SOA Appliances to extend InfoSphere Master Data Management Server security capabilities: looks interesting but I haven’t had a chance to read it in detail yet.
Mind you, that’s not the best description of the cats I’ve lived with: none of them have had collars, the word ‘owner’ is a bit suspect, and they all tended to play with mice before letting them escape under the cooker!
The paragraph about the user interface generator in my last post, or my other recent attempt to explain what it does, don’t really tell you very much. I hope this quick festive example provides a better idea about how user modeling and code generation can speed up user interface development.
First I needed to think of something Christmassy that might need a simple user interface. I apologise in advance, but I chose Christmas cracker jokes!! On the plus side, they’re really simple, and a basic create, read, update and delete interface makes perfect sense. So, I got started by creating a CRUD Joke UML diagram… and about five minutes later I stopped laughing to myself! Well, it’s funnier than most cracker jokes!
Perhaps a better role would have been, “Joke quality monitor”, with a goal of, “Maximise Christmas laughter”… or should that be minimise… well, you get the idea!
That’s pretty much it, I can then click the “Generate User Interface…” menu option, deploy the EAR it creates to an application server and fire up my web browser. It took longer to get this far through the blog post than it did to get a working user interface (admittedly I’m a very slow writer, but still, I think that’s pretty good).
At some point you need to put real code in for the commands to interact with the back end system, whatever that might be, but to start with the tool will generate a default implementation so you can quickly prototype and test the UI.
So that’s all there is to creating cracking user interfaces.
What am I doing?
You can follow this weblog using your favourite news reader or receive email updates using FeedBurner.
The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies or opinions.
Create a free website or blog at WordPress.com.
Create a free website or blog at WordPress.com.
Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
