Best Practices for Host Integrator Modeling
Pre-Modeling Activities
Review the host application and take advantage of host system experts to determine:
- What business function are you encapsulating?
- How many screens are required to complete the business function?
- What are the inputs and the outputs?
- Does the application ever change? How significant are these changes?
- What errors can occur? It's important to document all paths and error conditions the model might encounter. Even if some paths are of no immediate business concern, they must be recognized and handled in the model.
Determine the Number of Models Needed
You cannot access more than one host application with one model. If the application you want to develop needs to access data from more than one host application, you must create two models and develop an application that can share variables, which will allow you to integrate host data from two or more Host Integrator models.
Modeling Practices
As a common practice, you should avoid using both schemes together in one model because entity navigation paths and cursor positions can become out of synch.
Use tables to manipulate host application data
- There is less processing overhead using tables, because there is only one " round trip" needed to the server.
- Using SQL reduces the amount of coding necessary.
Set naming conventions
- Determine a standard notation for entities and attributes.
- Decide how to handle duplicate attribute names; there may be several fields called account_number among the host screens.
- If using COM objects, do not use a Visual Basic reserved word as an attribute name.
- Do not use reserved SQL words to name tables.
Determine global settings
- Set traversal operation preferences; traversal operations are usually automatically generated.
- Set entity and attribute generation preferences; these are usually created manually so you can generate only the entities and attributes that are necessary.
Create concise operations
Break large operations into a sequence of smaller operations, using alternate and intermediate destinations.
Minimize patterns used to identify an entity
- Create patterns at the top and bottom of each entity to ensure the entire screen is displayed.
- Do not add more patterns than necessary as this adds to the processing time to recognize an entity.
Parameters and Constants
- DefaultValue commands should have the Application parameter set to "Default value for server and design tool."
- When an attribute is available, all constant values should use TransmitToAttr.
- Correctly spell and set all constant values.
Timing for 5250 Models
When creating 5250 based models, define patterns for each of the input fields on the sign-on screen and on any screen where the timing of screen recognition is difficult because the AS/400 sends multiple writes to create the screen.
By defining these patterns for the input fields, the screen recognition process waits until these fields are ready for input. This ensures proper screen recognition and enhances model performance.
Optimizing the Model for Deployment
After you have completed your model, take these steps to prepare the model for optimum performance before deploying it to Host Integrator Server.
Delete unnecessary entities
- Include in your model only entities that contain necessary data or those that are intermediaries between entities containing this data.
- Do not create an entity for a host blank screen unless you have exhausted all other options. Blank screens have the potential of producing run-time entity signature ambiguity that could crash a session.
Delete unnecessary or unused attributes
To improve performance and reduce memory consumption, make sure that the attributes of each entity contain necessary data or input fields.
Delete all unnecessary operations
Validate the paths between entities to ensure they are traversable by the shortest route.
Reduce the screen signature
Review the screen signature of every entity in the model and reduce it to the minimum number of patterns required to uniquely identify the entity.
Optimize Traversal Operations
Before deploying the model, make sure the traversal operations are as efficient as possible. Open the model in off-line mode and follow these steps to review the operations for each entity:
Each traversal entity is named To<entity> and the destination entity matches this name.
Edit operations to remove the checkOperationConditions command if there are no pre or post conditions on this operation.
Troubleshooting Models
Validate the model using Validator
Use Web Builder to Create a Web Client
Use Web Builder to quickly and easily generate a Web application of the host
application model. Use this application to test your model functionality.
Test possible error conditions for each operation
You can test possible error conditions for each operation by inputting bad data or by reproducing mainframe error conditions.
Test the model parameters
- Test the write attributes, recordsets, procedures, and SQL statements.
- Every entity should be able to navigate to the home entity.
- Make sure that all screens, including error screens, can recover themselves (that is, they can navigate to the home entity).
Recognizing Screens as Entities
Invariably, your application will contain one or two screens that prove difficult to model. Problems range from unpredictable host data transmission timings to the host redrawing seemingly static portions of the screen. With these screens, it will take a little bit of extra observation and experimentation to model accurately. Evaluate the order in which the host writes the screen.
Watch the behavior of the cursor. Use model debug messages to look for events that could be causing the problem.
Synchronizing with the Host
Getting out of sync with your host is one of the most common problems encountered when modeling host applications. If your model works well in the Design Tool, but seems to malfunction in the server environment, the lack of synchronization is the most likely reason. Host sessions running on a Host Integrator server run faster than those in the Design Tool because there is no display to update.
Therefore, the server can expose synchronization problems that don't appear in the Design Tool.
This advice applies particularly to operations that scroll recordsets or perform other tasks within a single screen. Even on block mode host applications, Host Integrator will sometimes try to perform operations too quickly, producing incorrect results. See Host Integrator Synchronization Techniques for more information.
Working with Character Mode Host Applications
In character mode applications, the host is constantly moving the cursor to write data, so just waiting for the cursor to end up in the correct position after a host update may be sufficient. If the cursor is placed in varying positions but in the same place relative to some text, then a WaitFor command is recommended.
To ensure synchronization, end all operations with an appropriate WaitFor command. See Host Integrator Synchronization Techniques for more information.