Testing maps that contain relationships

When you test a map that contains a relationship transformation, you need to provide the following information in addition to the test data:

You specify this information in the Source Testing Data pane of the Test tab.

Tip: If the width of the Source Testing Data pane is not enough to let you see the complete menu options of the Calling Context combo box, you can expand the size of this area by putting the cursor over the right-hand boundary until you see the following symbol <-||-> and drag the boundary to the right.

If you are testing Relationships, select the appropriate generic object from the list of business objects, select Calling Context, and set the ObjectEventIds for the parent and child objects that match the ones you already set in the Test Data screen. The calling context you need to provide and whether you need to specify a generic business object depend on the type of relationship you are testing. This section provides information on the following:

Testing an identity relationship

To test point-to-point mapping (from Application 1 to Application 2) for an identity relationship you use three maps:

Figure 39 shows an example of a point-to-point communication of customer data between a Clarify application and an SAP application. If each application uses a unique key value to identify customers, these three business objects can be related with an identity relationship. Therefore, each map includes a cross-reference transformation rule. As each of these maps executes, these relationship methods access the calling context to determine the actions to take.

Figure 39. Maps involved in point-to-point testing of an identity relationship

To test the Create verb, you need to verify that a new application-specific key value in Application 1 (Clarify application in Figure 39) causes a new generic key value to be added for the generic business object and a new application-specific key value in Application 2 (SAP application in Figure 39). Therefore, testing involves three steps:

  1. Test the inbound map, App1_to_Generic, to send in a new key value from Application 1 and ensure that a new key value is generated for the generic business object. Follow the steps in Table 17..

    Table 17. Testing the App1-to-Generic map for an identity relationship

    To set up test run To verify test run
    1. Set the calling context to EVENT_DELIVERY or ACCESS_REQUEST by choosing the appropriate calling context from the Calling Context combo box.
    2. Enter the application-specific value in the key of the source business object. This value is unique for the key attribute(s) in Application 1.
    3. Run the test.

    4. Read the resulting generic key value in the destination business object, which has been added to the relationship table for the App1/Generic identity relationship.
    5. Save the destination business object data in a .bo file (e.g. App1_to_Generic.bo) by selecting the destination business object and choosing Save To from the Context menu.
  2. Test the outbound map, Generic_to_App2, to ensure that the new generic key value is sent to Application 2.

    To test an identify relationship in the outbound Generic_to_App2 map, you must provide the generic key value in your source Test Data. You might want to do either of the following, but they are both wrong:

    In both cases, Map Designer Express generates the RelationshipRuntimeException or NullPointerException. The error occurs because the generic key value has to be in the system for the SERVICE_CALL_REQUEST to work properly, and the relationship table is not the only place the generic key value is stored.

    The correct solution is to first run an inbound EVENT_DELIVERY (or ACCESS_REQUEST) map that uses the same identity relationship (as described in step 1). Follow the steps in Table 18 to test the outbound Generic_to_App2 map.

    Table 18. Testing the generic-to-app2 map for an identity relationship

    To set up test run To verify test run
    1. Set the calling context to SERVICE_CALL_REQUEST by choosing this calling context from the Calling Context combo box.
    2. Load the generic business object with the test results from the previous step (e.g. App1_to_Generic.bo).
    3. Run the test.

    4. Read the resulting application-specific key value in the destination business object, which is empty because Application 2 has not generated its key value yet.
    5. Save the destination business object data in a .bo file (e.g. Generic_to_App2.bo) by selecting the destination business object and choosing Save To from the Context menu.
  3. Test the inbound map, app2_to_generic, to verify that the new key value from Application 2 is associated with the new generic key value.

    When the calling context is SERVICE_CALL_RESPONSE, an identity relationship must cross-reference the ID in the application-specific business object to the ID in the generic business object. Therefore, for this test, you must specify the generic business object definition. Follow the steps in Table 19..

    Table 19. Testing the App2_to_Generic map for an identity relationship

    To set up test run To verify test run
    1. Set the calling context to SERVICE_CALL_RESPONSE by choosing this calling context from the Calling Context combo box.
    2. Set the generic business object by choosing the name of the appropriate generic business object from the Generic Business Object combo box. Map Designer Express adds the specified generic business object to the Source Testing Data pane.
    3. Load the application-specific business object with the test results from the previous step (e.g. Generic_to_App2.bo).
    4. In the application-specific business object, enter an application-specific value in the key of the business object.
    5. In the generic business object, enter the generic key value associated with the Application 1 key. This value should be the same key value generated for the generic business object in the EVENT_DELIVERY/ACCESS_REQUEST test (step 1).
    6. Run the test.

    7. Read the resulting generic key value in the destination business object, which should be the same value you entered in the generic source business object.
    8. You can use Relationship Manager to verify that the correct application-specific key values are associated with this generic key value for this identity relationship. For more information on Relationship Manager, see the User Guide for WebSphere Business Integration Express and Express Plus for Item Synchronization.

Testing for other verbs involves similar steps. For more detailed information on the actions of relationship methods for an identity relationship, see Implementing relationships.

Testing a lookup relationship

To test point-to-point mapping (from Application 1 to Application 2) for a lookup relationship you use two maps:

Figure 40 shows an example of a point-to-point communication of customer data between a Clarify application and an SAP application. If each application uses a special static code to identify geographic states, these three business objects can be related with a lookup relationship. Therefore, each map includes Custom transformations that do static lookups. For more information, see the "Static Lookup" activity example in "Example 3 of using the Activity Editor". As each of these maps executes, these relationship methods access the calling context to determine the actions to take.

Figure 40. Maps involved in point-to-point testing of a lookup relationship

To test the Create verb, you need to verify that an existing application-specific lookup value in Application 1 (Clarify application in Figure 40) causes the associated generic lookup value to be added to the generic business object and the associated application-specific lookup value in Application 2 (SAP application in Figure 40) to be added to its business object. Therefore, testing involves two steps:

  1. Test the inbound map, App1_to_Generic, to send in an existing lookup value from Application1 and ensure that the associated generic lookup value is obtained for the generic business object. Follow the steps in Table 20.

    Table 20. Testing the App1-to-Generic map for a lookup relationship

    To set up test run To verify test run
    1. Set the calling context to EVENT_DELIVERY or ACCESS_REQUEST by choosing the appropriate calling context from the Calling Context combo box.
    2. Enter the application-specific value in the lookup field of the source business object. This value is an existing lookup value whose data is already loaded in the App1/Generic relationship table.
    3. Run the test.

    4. Read the resulting generic lookup value in the destination business object, which has been obtained to the relationship table for the App1/Generic lookup relationship.
    5. Save the business object data in a .bo file (e.g. App1_to_Generic.bo) by highlighting the destination business object and choosing Save To from the Context menu.
  2. Test the outbound map, Generic_to_App2, to send in the generic lookup value and ensure that the associated lookup value is obtained for Application 2. Follow the steps in Table 21.,

    Table 21. Testing the Generic-to-App2 Map for a lookup relationship

    To set up test run To verify test run
    1. Set the calling context to SERVICE_CALL_REQUEST by choosing this calling context from the Calling Context combo box.
    2. Load the generic business object with the test results from the previous step (e.g. App1_to_Generic.bo).
    3. Run the test.

    4. Read the resulting application-specific key value in the destination business object, which contains the Application 2 lookup value.
    5. Save the business object data in a .bo file (e.g. Generic_to_App2.bo) by highlighting the destination business object and choosing Save To from the Context menu.
Note:
A lookup relationship can be tested for the SERVICE_CALL_RESPONSE calling context. However, this case usually only is required if the map is doing something else that requires the lookup data. The relationship methods for a lookup relationship in the Mapping API never write data to a relationship table.

Copyright IBM Corp. 2003