Summary set of planning questions

The following table lists the set of planning questions provided in this chapter. You can use this table as a worksheet for gathering information about your application. As you gather information, get copies of any documentation that can help in the planning, design, or development phases of the project.

Figure 18. Summary set of planning question
  1. Understanding the Application
    • What is the application operating system?
    • What programming languages were used to create the application?
    • What is the execution architecture of the application?
    • Is there a central database for application data? What type of database is it?
    • Is the application or its database distributed across multiple servers?
  2. Identifying the Directionality of the Connector
    • Does the connector need to send data, receive data, or both?
  3. Identifying the Application-Specific Business Objects
    • Do application entities have contained entities?
    • Are there application business entities that are the same type but have different physical representations in the application?
    • Are there application entities that reside in more than one location in the database but correspond to the same logical entity?
    • Are there batch processes associated with the creation of application entities?
  4. Investigating the Application Data Interaction Interface
    • Have there been any other efforts to integrate with this application?
      • What was the purpose of the integration?
      • Does the integration use interfaces that modify or retrieve information?
      • If the integration is able to process an event generated in the application, what is the mechanism used to trigger event processing?
      • Will your connector replace the pre-existing integration?
    • Is application data shared by other applications?
      • Do other applications create, retrieve, update, or delete this application's data?
      • What is the mechanism used by other applications to gain access to the data?
      • Is there object-specific business logic used by other applications?
    • Is there a mechanism that the connector can use to communicate with the application?
      • Does the API allow access for create, retrieve, update, and delete operations?
      • Does the API provide access to all data entity attributes?
      • Does the API allow access to the application for event detection?
      • Are there inconsistencies in the API implementation?
      • Describe the transaction behavior of the API.
      • Is the API suited for meta-data design?
      • Does the API enforce application business rules?
    • Are there batch clean-up or merge programs used to purge redundant or invalid data?
  5. Investigating the Event Management and Notification Mechanism
    • Describe the event management mechanism.
    • Does it provide the necessary granularity to establish the distinct object and verb?
    • Does event notification occur at a level that can support application business logic?
  6. Investigating Communication Across Operating Systems
    • Does the API handle the communication mechanism between the application operating system and the connector operating system?
    • If not, is there a mechanism available to handle communication across operating systems?

Evaluating the findings

As you assemble the answers to the questions presented in this chapter, you acquire essential information about application data entities, business object processing, and event management. These findings become the basis for a high-level architecture for the connector.

When you have determined what entities your connector will support and have examined the application functionality for database interaction and event notification, you should have a clear understanding of the scope of the connector development project. At this point, you can continue with the next phases of connector development--defining application-specific business objects and coding the connector.

Figure 19 shows a partial write-up of information about a sample connector. Figure 20 illustrates a high-level architecture diagram for an ODBC-based connector.

Figure 19. Sample results write-up
  1. Understanding the Application
    • Application is running on UNIX.
    • Programming language used is Visual C++ with the Microsoft MFC libraries.
    • Application is client-server.
    • Application has a central database. Type is RDMS.
    • Application is not distributed.
  2. Identifying the Directionality of the Connector
    • Connector will be bidirectional.
  3. Identifying the Application-Specific Business Objects
    • Business objects have contained objects. Contained business objects are:
      • Customer "Address "Site Use and Site Profile
      • Item "Status
      • Contact "n Phones and n Roles
    • Application business entities do not have different physical representations in the application.
    • Application entities do not reside in more than one location in the database.
    • No batch processes are associated with the creation of these objects.
  4. Examining the Application Data Interaction Interface
    • No previous efforts to integrate with this application.
    • Application data is not shared by other applications.
    • The application provides the OpenProduct API.
      • OpenProduct allows for Creates and Updates but not Retrieves and Deletes.
      • The API provide access to all data entity attributes.
      • The API allows access to the application for event detection. We can create an event table and poll for events at a specified interval.
      • There are no inconsistencies in the API.
      • The API has a batch interface.
      • The application is table-based, and the API is suited for meta-data design.
      • ...
Figure 20. Sample ODBC-based connector architecture

Copyright IBM Corp. 1997, 2004