HELP! how to contorl which site can be sent Bdoc?

[Former Member]

HI everyone :

I add 2 sites in the T-code SMOEAC,and assign them the same subscription.example:one of the subscription

contains the replication objects "BUPA_MAIN".

now when I create a BP in the CRM ,the system will sent Bdoc to both the sites.

iif I want to choose only a site which i request when the BP save,how can i do?

thank you!

[former_member209156]

Hi Nikey,

There is no possiblity to setup the system in such a way than when you save the change to business aprtner you then get to choose which site the change is sent to: either a subscription has been maintained, in which case the data or sent, otherwsie they are not sent.

You do, however, have an option to restirct which the BUPA_MAIN-relevant data are sent to each site by using citeria fields.

Some publications (and the replication objects they are based on) are delivered as type "Simple bulk" which does not give you the opportunity to assign criteria values for filtering. This applies to BUPA_MAIN

You therefore have to re-create the publication. To do that, first deleted the

subscriptions, publications and the replication object, then recreate the replication object as type "Simple intelligent".

Afterwards you can create a new publication via wizard of type "Simple intelligent (msg)" assigned to the BDOC-Type BUPA_MAIN.

Then, you will be able to select some "filter criteria".

The reason for deleting the "old" publication is, that you are not allowed to assign a BDOC-Type to more than one publication

But please keep in mind that there is no realignment supported. So you should only use fields for filtering, which cannot be changed after-wards (such as the transaction type).

This is the "simple" solution for filtering on fields. This will not provide complex filter criteria.

If you need this, you are able to create a filter function in R/3- and/or CRM-Inbound and -outbound.

If you need this, you are able to create a filter function in R/3- and/or CRM-Inbound and -outbound.

If you want to keep the control about the upload trigger, you can add

an additional module in transaction CRMC_BUT_CALL_FU, position > 200000.

BUPA_MWX_BDOC_BPS_FILL_CENTRAL. Within this new module, you can delete

all partners within the complex structure that you don't want to upload.

You can use every criterion you are interested in.

I hope this helps.

Brian.

[Former Member]

thank you very much Brian Patterson!

Yestoday I tried to recreate the Replication object "BUPA_MAIN" as a "Simple Intelligent" ,BUt not successful,

More serious,The middleware in the IDES doesn't work.

I use the T-code ST05 to trance when a BP is saved.SO I found a function "/1CRMGC/HTBUPA_MAIN_RRR".

in this function i Modificationed some codes:

• fill the recipient list: get dependent sites / sitetypes

FREE recipients[].

CALL FUNCTION 'SMOH_FILL_RECIPIENT_LIST'

EXPORTING

i_calcrec = lt_sites

i_sendrec = send_to_sites

CHANGING

ct_recipients = recipients.

*get bp information by rootid or queue name of header add by yueshuai

select single * from but000 into ls_but000 where partner_guid = header-root_id.

if sy-subrc = 0.

*delete the site by the bp number from header

loop at recipients into ls_recipient.

if ls_recipient-SITE_ID = '20CF3083320C1EE18AC88598551B453D' and ls_but000-partner not BETWEEN '0005300000' and '0005399999'.

delete TABLE recipients from ls_recipient.

elseif ls_recipient-SITE_ID = '20CF3083320C1EE18AC34FD07153653D' and ls_but000-partner not BETWEEN '0005100000' and '0005199999'.

delete TABLE recipients from ls_recipient.

endif.

endloop.

endif.

SO the Problem is solved,BUT I don't know wheather this way is right ?

[rohit_sharma2]

Hello,

Fucntion /1CRMGC/HTBUPA_MAIN_RRR is a generated module and it is advised to never change it manually. You may have your code edits made in this FM as of now, but the next time this FM is generated via GNRWB or SMOGTOTAL etc. your changes would be lost. So it is never a good practice to make code changes in generated modules.

You should try the suggestion given by Brian.

Regards,

Rohit