Troubleshooting for the ALE Module
This
section describes problems that you may encounter when starting
up or running the ALE Module. It covers the following subjects:
Startup problems
The following subsections provide suggestions for common
startup problems.
Connector cannot log on to or register with the SAP application
If the connector cannot log on to or register with the
SAP application:
- Check that the SAP application is available.
- Check that you have properly set the standard and connector-specific
connector configuration properties:
- Check that the required WebSphere MQWebSphere MQ queues have
been created and that their corresponding configuration property
correctly specifies their name.
- For request processing, check the Sysnr, Client, Hostname, and
Modules properties.
- For event processing, check the gwService, Hostname, RfcProgramId,
and Modules properties.
For more information, see Configuring the connector, Appendix E. Connector-specific configuration properties, and Troubleshooting the connector.
- Verify that the user name and password set up for the connector
has the appropriate level of privileges.
Connector is not polling events
If your connector is not polling events from the SAP application:
- Check that the verb application-specific information for the
desired verb has been modified to have the correct message type,
message code, and message function.
- Check that the verb AleOutboundVerbs exists and has a list of
valid verbs.
Connector appears to be polling but events are not being
picked up
- Check that the event queues (SAPALE_Event_Queue and SAPALE_Wip_Queue) have been created correctly and that polling is being done
on the event queue.
- Verify that the following are running on your system:
- Verify that the ALE configuration within the SAP application
is correct; for more information see, Overview of the ALE Module.
- Check that the connector has made at lease one poll call; doing
so installs the function modules for event processing.
- Check that a message has been written to the wip queue and has been moved to the event queue.
Event handling
The connector logs information about successfully processed
IDocs in a JMS-MQ event message (in the queue specified in the SAPALE_Event_Queue configuration
property) to the EventState.log file. This file is located in the directory specified in
the AleEventDir configuration
property.
Note:
Each event message can contain multiple IDocs, each
of which represents a business object.
If the connector goes down before it processes all IDocs in the
current event message, it uses the EventState.log file during recovery to ensure that it sends each IDoc only once
to the integration broker.
Important:
The connector does not create the log file automatically
the first time it processes an event. You must create this file
for before you run the connector for the first time.
The format of the log file is:
TID: OS, 1S, 2F, 3U
where <TID> is the
current transaction ID being processed, and each number represents
the sequence number of all work units in the event message.
For example, if the connector has successfully processed three
of the first four IDocs in the current event message, the second
IDoc failed processing, and the connector has not yet finished processing
the current event message the EventState.log file might show:
<TID> :: OS, 1F, 2S, 3S
If the connector went down before processing the entire event
message, at startup the connector will use the information in the
log file to resume processing the events in the message at the point
where it had stopped processing. The connector reads the log to
get the transaction ID of the event to be recovered, the latest
work unit, and the status of each work unit. Then the connector
begins sending to the integration broker the business objects that
represent each IDoc in the event message with a sequence number
greater than the last number in the log file. In the previous example,
the connector will processing the fifth IDoc in the current event
message.
The connector keeps the contents of the log file in memory to
enhance performance. It accesses the file on disk only to update
it with a new entry. The connector reads the log file only at recovery
time.
For information on how the connector uses the EventState.log file in the recovery process, see Failure recovery.
Failure recovery
Note:
These recovery steps do not apply if a disk
failure occurs or if a disk is full.
To recover from failures during event notification, the connector:
- The connector processes IDocs from the JMS-MQ message in the event queue (specified in the SAPALE_Event_Queue configuration
property). When it successfully processes a IDoc, the connector
logs an entry in the EventState.log file.
- If none of the work units in the event message fails processing,
the connector moves the event message to the archive queue with
an IDocProcessStatus value of success.
- If any of the work units in the event queue message fails processing,
the connector will move the event message to the archive queue and
update the IDocProcessStatus value of partial.
- After the connector processes all IDocs in an event message,
it clears the EventState.log file and begins writing entries to it for the next event
message.
- If the connector goes down before it processes all IDocs in
an event message, it uses the information in EventState.log to determine where to begin processing during the recovery
process. When it comes back up, the connector checks whether there
are any entries in the log file.
- If there are no entries, the connector sends all IDocs in the
event message to the integration broker.
- If there are entries, the connector will use this information
to resume processing an event message at the point where it had
stopped processing. The connector reads the log to get the name
of the event message to be recovered and the latest IDoc sequence
number. Then the connector sends to the integration broker each
IDoc in the event message with a sequence number greater than the
last number in the log file. In this example, the event message
is moved to the archive queue and the IDocProcessStatus is updated according to the status of each work unit in the EventState.log.
Using the log file prevents the connector from sending the same
IDoc multiple times to the integration broker. The connector keeps
the log file in memory to enhance performance. The connector accesses
the file on disk only to update it with a new entry, and reads the
log file only at recovery time.
Note:
If there is no IDoc in the event message whose sequence
number is greater than the last number in the log file, the connector
went down after processing the last event but before archiving the
event file. In this case, the event message is moved to the archive
queue and the IDocProcessStatus is updated according to the status of each work unit in the EventState.log.
Recovery from business object creation errors
If the connector has created only the header portion of
the message in the WIP queue but not the data portion, this procedure
will recover the data portion of the message.
- Examine the SAP connector log for error messages pertaining
to the business object's name, message type, or verb.
- Make the appropriate corrections to the business object definition
or the connector configuration.
Note:
Configuration changes may include changes to WebSphere
MQ queues. For more information, see
Prerequisites to running the ALE Module..
- Restart the connector.
Request processing
If a subscribing business object is not being processed
by the ALE Module, then:
- Check that the vision connector framework is set to call the
ALE Module. The Modules property
must be set to ALE.
- Check that the connector subscribes to the business object.
