Define SAP EM - manual config or transport?

[Former Member]

Hello,

This may seem like a silly question but I'm confused about Event Manager definitions in ECC.

I work in Basis and I've been asked by the EM project team to open the client on our QA ECC system to manually define the Event Manager in SPRO.  The program in ECC is /SAPTRX/SAPLASC0 and the SPRO path is "Integration with Other mySAP.com Components" --> "Event Management Interface" --> "Define Application Interface" --> "Define SAP EM".

Is this normal?  Wouldn't a transport be better? 

This configuration is cross-client, so wouldn't it be better to define all of the upstream Event Managers in the Dev system and move all 3 EM configurations up with a transport, rather than opening the QA and Prod clients for manual adjustment?  I do realize I have to make sure that all of the logical systems and RFC destinations are defined correctly in all systems. 

Our EM is hosted on an external SCM system.  Dev is called SCD, QA is SCQ, and Prod is SCP.  What I propose would look something like this in program /SAPTRX/SAPLASC0.  I propose that this whole configuration should be defined in Dev and transported up without opening the client and manually making the changes in QA and Prod.

Event Manager  EM Log. System  SAP EM Version  Local  Dest.                    Sync  Description

SAPEM0         SCDCLNT110      SCM4.0                 SCDCLNT110_NON_TRUSTED     X   Development EM

SAPEM1         SCQCLNT300      SCM4.0                 SCQCLNT300_NON_TRUSTED     X   QA EM

SAPEM2         SCPCLNT300      SCM4.0                 SCPCLNT300_NON_TRUSTED     X   Production EM

Versions:

ECC 6.0 ehp3

SCM 7.0 ehp1

Would this cause a problem with the EM application or functionality?  Does EM depend on only one Event Manager name and definition?  Does having 3 separate Event Manager definitions make the application configuration for the project team unnecessarily complex?

If there are any notes or documentation on Event Manager definitions normally being configured manually, I would love to see them.

Thanks in advance for any help you might be able to share.

Rob Sanchez

[former_member190756 · Accepted solution]

Hello Rob,

there is no problem with you proposal. Setting up all 3 configs is possible and should be the normal way.

Best regards,

Steffen

[Former Member · Accepted solution]

Hi Steffen, thanks for your response.  I'm still confused about this issue.

The objection I'm getting from the project team is that if all three configurations are defined, then that means all three configurations are active in the upstream systems. 

If all three configurations are available in the Production ECC system, then as the code loops through all available Event Managers it could issue events to each one.  In order words, just because the Dev and QA Event Managers are available to the Prod ECC system, that doesn't mean we want to use them!

I would think that the Production ECC system would only be interested in the logical system of the Production Event Manager, and would not try to issue events to the non-Production Event Managers.  This must be controlled from other piece of config I imagine!

Thanks

Rob

[former_member583013 · Accepted solution]

Rob / Steffen,

The problem with loading all 3 as EM systems also implies that you need 3 sets of related configuration for AOTs and ETs which in turn implies that your QA testing is not testing what will actually be used in production!

The whole purpose of making the EM system a "logical" system is to have all your config point to it and then change the technical properties of it in each system. EM needs a concept like an IDoc partner profile where you can maintain the link between logical and physical systems as master data.

[former_member190756 · Accepted solution]

Hi Rob,

couldn't you just transport your AO Type with the relevant setting for the EM system?

i.e. in your AO Type only the entry for the EM system differs all other settings are the same.

Other possibility is to set the AO TYpes to inactive in /SAPTRX/ASC0AO. Then you would have to activate the relevant config in the prod system. But thgis would then be the only settings you have to do there.

Best regards,
Steffen

[former_member583013 · Accepted solution]

Steffen,

The sole purpose of a QA system is to test your transports. I.e. will your config and development work as designed in production? Any config changed in QA and then again in production is not a good idea.

By changing the RFC destination in production, this is not a config change but a piece of technical master data is is quite acceptable to change as apposed to the changing of AOTs and including all 3 landscape environments with their own config.

The table is designed to be changed in each system, it should just be categorized as a master data table and not a transportable config one and we'ld all be happier 😉

[former_member190756 · Accepted solution]

Hi Kevin,

ok i will propose to make this change.

But if you can change RFC destinations in a Prod system why is it then not possible just to have one entry for the EM RFC settings and change only the entry in SM59.

Best regards,
Steffem