cancel
Showing results for 
Search instead for 
Did you mean: 

queue blocking model activation

Former Member
0 Kudos

Dear All,

Could someone re-assure why does or rather why should failed initial transfer queues (master data like material, PDS, inforecs) from a logical system X be the reason for failure of activation( in b/ground where I canu2019t ignore the msg) of models in logical system Y where it terminates citing this Q message. X and Y are from different BSG

Regards,

Loknath

Accepted Solutions (1)

Accepted Solutions (1)

Former Member

Loknath,

Well, the question is a little unclear, so let me just describe a small scenario in hopes that within my statements, your question is answered.

SAP core interface establishes partnership between three logical systems: A <> X and B <> X, where A and B are ERPs, and X is an SCM system..

A has BSG 'BA' assigned to it. B has BSG 'BB' assigned to it. X will not allow the same BSG to be assigned to more than one logical system.

A has certain master data that is to be replicated in X. B also has certain master data that is to be replicated in X.

SCM by design will not let A transfer any master data (add/change/delete) that already exists in X, if the source of the X master data is a different BSG (not 'BA'). Likewise, SCM by design will not let B transfer any master data (add/change/delete) that already exists in X, if the source of the master data is another BSG (not 'BB').

This design prevents the master data between the three systems from being inconsistent. A<>X, and the master data they share, is always consistent; B<>X is also always consistent.

If you are getting this message, then you have to delete the existing master data in SCM that belongs to the 'wrong' BSG, before you can transfer.

Best Regards,

DB49

Former Member
0 Kudos

Dear DB49,

Thanks for the reply. I should have elaborated.

The situation is something like this

In ECC system A: I am activating an integraton model for some data that is not present in any other ECC system

I note that an APO inbound queue that has its origin in some other ECC system B is is coming as a pop during activation of int model above in A e.g. I am actiavting a model for Planned ind .requirement and I see a warning of a queue that has something to do with some material fault because in system B

APO being system X

Now both are differnt business system groups XA and XB

Question is..why should a queue of some completely unrelated data and system come in the way of model actiavtion in some other system. I can correct the faulty queue but there would be tons of them from other systems that doesnt need my attention, I am interested in activating the model in system A and the sysfail queue is not of system A orders.

Regards,

Loknath

Former Member
0 Kudos

Loknath,

there would be tons of them from other systems that doesnt need my attention

The do need your attention if they are for the same master data object, but from a different BSG.

Transactional data (such as PIRs) normally cannot move unless the underlying master data in SCM is from the same BSG. Most master data objects in SCM can have one and only one BSG. You therefore must concern yourself with cleaning all inconsistent master data before the first transactional IM can be successfully activated.

I don't know how you got in a position whereby you have multiple BSGs with master data assigned, but if the BSGs are not being used, the master data should be eliminated from SCM to prevent these types of problems.

Best Regards,

DB49.

Former Member
0 Kudos

Dear DB49,

On your insistence I looked at the connectivity settings for the first time and do note that same BSG is indeed assigned to all the source systems and APO system. Error handling: Strict (INITIAL)

BUT

This raises another question in my mind.

I see that integration models fail citing queues only in certain source systems though the queue in question is from a differnt logical system (citing some fault with some element of master or trx data).

Q1: Why does this happen ? because of ANY faulty inbound queue, the integration models should fail in all the systems but that is not the case.

Q2: I would assume that with RIMODACT, I can ignore errors as they arise during activation (in b/g) and hence I should IDEALLY use RIMODACT in all the systems for model activation (emphasis mine) to be successful. It is currently RIMODAC2 in all the systems.

We do solve all the root causes of failed queues but you would appreciate that cant be done instantaneously everyday when I am talking on tons of data, so model failures may prove costly. ESPECIALLY given that the queues being cited are from different source system for differnt material and different document altogether(no remote relationship of anykind to deter the activation of model failing). I mean there is absolutely no relationship for the model to fail..

Regards,

Loknath

Former Member
0 Kudos

Loknath,

You are saying (I think) that all of your ECCs are assigned to the same BSG.

Although SAP allows this, it is not recommended. According to Best Practices/Connectivity

If you plan to connect more than one ECC system to the SCM system, we strongly recommend that you create a separate business system group (BSG) with a unique name for each ECC system (or each ECC client). This way, you can keep the data processing separate and avoid data inconsistencies between the systems.

.

Now you are facing the issues that they warn you against.

BSGs are useful to help maintain material master/product master consistency. There are many different permutations of data inconsistencies that can adversely affect your processing, when you use a single BSG for multiple ECCs. They are dependent upon the number of systems you are connecting, the types of queues you are using (Inbound vs outbound), and the types of IMs you are using in each of the source systems. I can't say from here which combinations are giving you the most heartburn. I will say that if a given material exists in more than one ECC, and you have material IMs CIFfing data to a single SCM, and all the ECCs have the same BSG, you will forever have issues with queue blocks.

I would assume that with RIMODACT, I can ignore errors as they arise during activation (in b/g) and hence I should IDEALLY use RIMODACT

Surely you are joking. Or, maybe with today's dismal economic outlook, you are trying to generate some job security for yourself, by guaranteeing future work.

RIMODACT and RIMODAC2 perform the same task. Errors are never acceptable in the execution of either. Every time you ignore (bypass) an errored LUW, you are just postponing solving the problem. Any time you delete the faulty LUWs, you are enshrining inconsistency in your systems.

It is uncommon to run RIMODACT in a stable production system. IM re-generation and re-activation is usually done through regular batch jobs. In a stable system, SMQ1 (and/or SMQ2 for inbounds) are reviewed regularly, and cleared. And when I say 'cleared', I mean 'the root cause is discovered, fixed, and then the IM's re-generated and re-activated'. It is almost never appropriate to delete an LUW and just walk away from it.

BP Connectivity

http://help.sap.com/bp_scmv250/BBLibrary/Documentation/B02_BB_ConfigGuide_EN_DE.doc

Monitoring CIF

http://service.sap.com/~sapidb/011000358700000715082008E

Best Regards,

DB49

Former Member
0 Kudos

Hi DB49,

I did mean a single BSG system here connected to multiple ECC. You are saying, whatever might have been the (emphasis mine) initial considerations to do such, this is not a good practice (to have single BSG)

Of course, we do solve the root cause and dont simply delete or ignore queues. we run CCR program often to figure and solve errors that are mysterious and need leisurely time.

Thanks for the reassurance(that models will always fail for some or the other queue block).

Regards,

Loknath

former_member209769
Active Contributor
0 Kudos

I am surprised no one gave you the correct answer. You could use the option "Ignore faulty queue entries" under 'special CIF settings" in RIMODAC2, and then any unrelated blocked queues from any connected system will not cause issues for you.

Even if you are trying to activate the integration model in the foreground, you can always choose teh option of "ignore" to go ahead with your activation. Hope this is helpful for you.

Answers (0)