** TEAM FPM ** – Tracking of FPM Events sent via Message Channel API
In my recent blog ABAP Push Channel for FPM Events I have described the capabilities of Floorplan Manager to broadcast FPM Events (instances of class CL_FPM_EVENT) via ABAP Message Channel (AMC) and ABAP Push Channel (APC) to FPM applications.
FPM Events can be sent basically with the FPM Message Channel API. Up to now this API was represented solely by static method SEND of class CL_FPM_CHANNEL_MANAGER.
Recently customers have asked for a possibility of being notified, if an FPM Event could not be delivered to the registered receiver for technical reasons. For instance, think of an FPM application that is spread to multiple browser sessions, which are kept in sync with the help of the FPM Message Channel API. If one of the browser sessions is closed with or without intention, then the remaining sessions should “know” about this.
With SAP Note 2571393 we provide a new ABAP interface IF_FPM_CHANNEL_MANAGER that fullfills the above mentioned requirement. An instance on this interface can be retrieved via class CL_FPM_CHANNEL_MANAGER_FACTORY, method GET_INSTANCE. Furthermore you should implement a handler (ABAP command SET_HANDLER) that listens to event IF_FPM_CHANNEL_MANAGER~FAILED_DELIVERY.
The method SEND of interface IF_FPM_CHANNEL_MANAGER has the following signature:
IO_EVENT: FPM Event to be sent
IV_SEMANTIC_ID: Semantic ID (AMC Channel Extension ID)
IV_SCOPE (optional): AMC Channel Scope
IV_TRACKING (optional): Boolean parameter to enable the tracking
IV_TRACKING_TIME (optional): Time to track the delivery, default value is five seconds
IV_TRACKED_RECIPIENTS (optional): Number of tracked recipients, default value is one
RV_MESSAGE_ID: Tracking ID
So when sending an FPM Event via ABAP Message Channel you can apply for a tracking of the delivery by using importing parameter IV_TRACKING. If the tracking could be successfully initialized you will get an Tracking ID (returning parameter RV_MESSAGE_ID) as response. If tracking could not be initialized, then a “weak” exception CX_FPM_AMC_NO_TRACKING is being raised. If the tracking has been initialized and if the receiver did not confirm the delivery within the given tracking time (importing parameter IV_TRACKING_TIME), then the event IF_FPM_CHANNEL_MANAGER~FAILED_DELIVERY is being triggered, it specifies also the corresponding Tracking ID.
The importing parameter IV_TRACKING_TIME scales with the overall APC/AMC and browser performance. The default value (five seconds) should work in most of the cases. For slow environments it might be necessary to double or triple the default value.
With the right Support Package level you can test the new feature with application FPM_TEST_APC_2_MONITOR. This application shows SFLIGHT data on two different monitors (browser sessions).
The first monitor is showing flight data in a List UIBB. Here you can select multiple lines and change the Airfare price. See Figure 1.
Figure 1: First Monitor of FPM application FPM_TEST_APC_2_MONITOR
The second monitor (see Figure 2) can be launched with button Display Chart. It shows a Pie Chart of the Booking Total column data.
All your updates done in the first monitor will be immediately shown in the second monitor. Vice versa, all your selections done in the second monitor will be immediately reflected in the first monitor. It feels like one application, but technically you run two browser sessions 🙂
Figure 2: Second Monitor of FPM application FPM_TEST_APC_2_MONITOR
Both GUIBBs (List and Chart) make use of Feeder Class CL_FPM_TEST_APC_2_MONITOR. Here you will find all the relevant coding.
So let’s check finally, if the tracking of sent FPM events really works! For instance, close the first monitor and select in the remaining second monitor some pies in the chart. After five seconds (default tracking time) you will get the message Receiving session lost (see Figure 3). You may think of another visualization or procedure when using this feature in your own application. It depends on how the ABAP event IF_FPM_CHANNEL_MANAGER~FAILED_DELIVERY is handled in the Feeder Class or AppCC.
Figure 3: Second Monitor after closing the First Monitor