Based on our particular design, it was helpful to use SAP Alerts Management to notify MIS resources of errors in both CRM Leasing Contracts as well as when those contracts error out in FI-LAE. While the CRM Action Definitions provide a configurable way to trigger alerts, FI-LAE does not. Find out how an implicit enhancement was used to raise SAP Alerts. Here are few basic areas to consider: *Consider Activating Central Alerts Management* Yes, you could maintain Alert Category definitions in both the CRM and ECC systems that are needed to enable the SAP Leasing Solution, but my guess is that you also have a BI system too. That makes three instances that all happen to leverage the SAP Alerts Management capabilities. Currently, both CRM and BI have configurable means of triggering alerts. In the case of CRM, Action Definitions can easily trigger defined actions. There is even a BADI available to fill in more containers for SAP Alerts. Also, when BI Process Chains fail, you can notify responsible parties with SAP Alerts. There are other functions that can trigger SAP Alerts like CCMS and through various APIs (which you'll use) any program can trigger events too. So, all you need to do is establish a central Alerts Management server and point all your environments there. This is simply done by defining an RFC connection (SM59) with a userid that will also be given appropriate authorization objects (which are well documented in the help.sap.com files for SAP Alerts Management). This is also the userid that will appear as the author/sender of the notification e-mails. Use transaction *SALRT1* to set the central server RFC. Do this in all your systems. The central server's configuration would have a value of NONE for the RFC. In our case, we have a Solution Manager system that we use for all sorts of things including Central User Administration, Service Desk, etc. so it also makes a perfect central alerts server. *Define your Alert Categories* Using transaction *ALRTCATDEF*, I created two alert category definitions. ZCSI_CONT_ERROR is triggered from CRM whenever a contract is saved with an error. ZCSI_LAE_ERROR is triggered from ECC whenever a contract transaction results in an error. I also happened to create a customer defined Alert Classification for all our company defined alerts. I am a novice in SAP Alerts Management so just starting to begin understanding the methods and madness behind it. Those that are workflow experts and better understand how "Containers" are set and processed will be better off than others. I'm going to keep most of the ALM (SAP Alert's Management) stuff brief as I expect you'll find better resources elsewhere. I kept things relatively simple. I used fixed e-mail recipients based on userids. I could consider other features like e-mail based on roles or defining rules. I'm also defining the texts that will appear in the e-mail (or pager, SMS, etc.) messages instead of using the "Dynamic Text" feature. The key to success and power is defining the Container elements. Applications pass values to Alerts Management through a Container. This is basically a special table that passes values with element names and the associated values. For example, you can define an element of "SYSID" based on the data element in structure SYST-SYSID. This element can then be reference in the e-mail text as a variable, e.g. &SYSID&. Since we are in the process of implementing and anticipate seeing messages coming from different systems and clients, I included both System and Client as container elements. I also included items like Object_ID which is equivalent to the CRM Contract. 
*Trigger Alerts with CRM Actions* CRM Actions are clearly HUGELY powerful structures. I won't bother to go into all the details of how they are defined. I'll just show you what the end processing type looks like within the action definition so you'll recognize it. I followed menu path SPRO - Customer Relationship Management - Basic Functions - Actions - Actions in Transaction - Change Action Profiles and Actions. I added an Action Definition, ZCSI_ERROR_CHECK into the action profile we use for SAP Leasing Contracts. I created a processing type of Trigger Alert. Since the central alert server has been established, the "drop-down" will automatically populate the values via the RFC connection. That is why it is best to have your alert defined in advance. This screen, though, does give you the ability to define your alert category directly without going to ALRTCATDEF first. 
You can also implement a BADI *ALERT_EXIT_LOCAL_PPF *method* GET_ALERT_DATA *to fill in values of the CT_CONTAINER table. The following is an excerpt from the method as a very simply means of sending container values:
*Trigger Alerts with CRM Actions* CRM Actions are clearly HUGELY powerful structures. I won't bother to go into all the details of how they are defined. I'll just show you what the end processing type looks like within the action definition so you'll recognize it. I followed menu path SPRO - Customer Relationship Management - Basic Functions - Actions - Actions in Transaction - Change Action Profiles and Actions. I added an Action Definition, ZCSI_ERROR_CHECK into the action profile we use for SAP Leasing Contracts. I created a processing type of Trigger Alert. Since the central alert server has been established, the "drop-down" will automatically populate the values via the RFC connection. That is why it is best to have your alert defined in advance. This screen, though, does give you the ability to define your alert category directly without going to ALRTCATDEF first. You can also implement a BADI *ALERT_EXIT_LOCAL_PPF *method* GET_ALERT_DATA *to fill in values of the CT_CONTAINER table. The following is an excerpt from the method as a very simply means of sending container values:data ls_container type swcont.
ls_container-ELEMENT = 'SYSID'.
ls_container-TAB_INDEX = 2.
ls_container-ELEMLENGTH = 8.
ls_container-TYPE = 'C'.
ls_container-VALUE = syst-sysid.
append ls_container to ct_container.
I haven't found that the TAB_INDEX matters much, but I filled it in anyway. Keep in mind, I'm neither a formally trained ABAPer and I'm a novice at alerts. I'm sure someone will comment and or criticize accordingly.
*_Triggering Alerts from FI-LAE (The Lease Accounting Engine) - Creating the Function Module_*
There are a few differences, I've found, and may be based on my novice status, in how you use the SAP Alerts Management APIs and configuring the central server from ECC versus the other systems. Again, maybe an ALM expert will bail me out. Anyway, I found that you need to maintain table TWPALRTDST using SM30 to specify the central RFC destination. Don't know why, but I did it. Laugh and ridicule, but what the heck.
You'll want to create a function module that controls the logic for triggering the alert category definition. Took awhile to figure out how to take advantage of the macros and what to literally INCLUDE where, but here is what I've got. I created a FM that takes in the RETURN table from FI-LAE as well as the standard deep structure of CTY_ITEM which contains all the info about the FI-LAE contract item you are processing. From this, I also make sure that I don't process the alerts if this contract item is being processed in a Dialog, in a Test Run (via simulation in FILATEST), or if the processing status is ‘1'. Long story based on FILA_ITEMS_PROCESS_NEW function module, but that is a topic for a future blog.
FUNCTION Z_CSI_TRIGGER_LAE_ALERTS.
*"---------------------------------------------------------------------
*"*"Local Interface:
*" IMPORTING
*" REFERENCE(IT_RETURN) TYPE BAPIRET2_T
*" REFERENCE(CTY_ITEM) TYPE FILAE_CT_ITEM OPTIONAL
*"---- ----------------------------------------------------------------- * If LAE is being run on-line, then an alert isn't necessary * since a screen will be displayed. *
* Additionally, if this is a test run, e.g. simulation, an * alert isn't necessary as well. *
* check for these conditions before performing any further*Enhance FM LAGF_MESSAGES_HANDLE in FI-LAE to call your function module* This will seem like the scary part. You need to create an enhancement in one of the SAP delivered function modules. I've been assured that this is truly an enhancement and not the dreaded modification and should be protected from upgrades, OSS Note application, etc. I guess I'll believe it when I see it, but I've gone ahead with it. Basically, call up the function module. Under the "Function Module" Menu, select "Enhance Source Code". The screen will appear open for edits. Follow menu path "Edit - Enhancement Operations - Show Implicit Enhancement Options. If you page down to the end of the FM, you'll see a bar of text with a line of """"" that constitutes the "enhancement point. Basically for this particular FM, you can only add your code at the very end. In this case, this is ideal. Click your cursor on this line and follow menu path "Edit - Enhancement Operations - Create Enhancement". You'll get some pop-ups to fill in the important information to define the enhancements. In this particular case, you are enhancing code, not declarations. *
