cancel
Showing results for 
Search instead for 
Did you mean: 

Interlinkage for ACT/EMP and OPP/EMP

Former Member
0 Kudos

Hi all

I did not know whether to post this here or in a middleware forum but I thought I would try here first.

We have made the EMPLOYEE_WRITE intelligent to cut down data transfer and enhance the speed of the Employee calendar

We have made it so that the the employe record is only sent to mobile according to whether they are assigned to the org model or not.

The issue that we have is when someone leaves a role of even leaves the company and is removed from the org model which causes transactions to have the employee entries missing.

Is it possible to create an interlinkage for OPP/EMP or ACT/EMP on SFAMITABT to deal with this so that the employee record is brought to MSA by virtue of its attachment to a transaction?

It does not look to be there as standard although contact person is on the SFAKNA1 field

Thanks

James

Accepted Solutions (1)

Accepted Solutions (1)

former_member192750
Active Contributor
0 Kudos

James,

I do not see any problem doing this, the new interlinkages should work fine - you would need to pick the right interlinkage tables where the employee to object relation is stored.

Regards,

Ankan

Former Member
0 Kudos

Ankan,

This is James' colleague, just want to update that while creating Interlinkage ACT/EMP i am able to see only SMOKVBEZ4 instead the relation we are looking is available in SMOKVBEZ11,and with the OPP/EMP Interlinkage also i am able to see only SMOKVBEZ9 but we want SMOKVBEZ8.

If you see SMOKVBEZ11 and SMOKVBEZ8 tables ,you can find that SMOKVBEZ11 has employees assigned to Activities and SMPKVBEZ8 has employees assigned to Opportunities, so if you can throw some light on this that would be great.

Thanks and Regards,

Anil Kumar.

former_member192750
Active Contributor
0 Kudos

Anil/James,

The choice of the interlinkage tables comes from the Potential Criteria Fields maintained for the parent replication object - please add the necessary potential criteria fields to OPP_WRITE and ACTIVITY_OBJECT (type I). I hope you're trying this out on your test landscape first

Regards,

Ankan

Former Member
0 Kudos

We certainly are using test landscape

We can only create interlinkages in development and transport specifically to stop people like me from getting too enthuiastic

We will enhance the replication object and see how we fare

Thanks and will update with the results

James

Former Member
0 Kudos

Hi,

but before transporting this to QA and Prod please delete the bulk employee subscription there as it might cause some trouble...;-))

Regards,

Wolfhard

Former Member
0 Kudos

Thanks Wolfhard

We have had employee as intelligent for quite some time now in all landscapes so the bulk subscription exists no longer

Former Member
0 Kudos

Hi,

another comment:

There is a (small?) restriction of using interlinkages in your case.

The R&R for interlinkages is only working fine for scenarios where there is no update of the key in the leading object. Only delete and insert is allowed respectively supported.

That means that it should not be allowed to change the employee in the activity or opportunity directly. You would need to add the new responsible person before and delete the existing one afterwards.

Regards,

Wolfhard

Former Member
0 Kudos

That is very helpful - thanks

Would the same be the case for ACT/CON and OPP/CON or is it just relevant for the employee ones?

Former Member
0 Kudos

Hi,

I guess it is relevant for all IL - we got the following answer from the support for a similar project issue:

#########################################################################

...

But there is one more issue, which should be checked in your case. Normally

CDBD_PARTNER does not fit the conditions to be used as interlinkage

table. This is due to the fact, that there are simple updates on that

table for interlinkage relevant changes (BP PARTNER GUID for example).

But such updates are not handable by our framework. We need DELETE/

INSERT information, if interlinkage relevant fields are changing. Why do

we need them ?

The reason is the following:

Whenever a change on partner A (CAPGEN) of SRV_WRITE is triggered to

partner B (CAPGEN), we have to trigger a realignment for CAPGEN A and

CAPGEN B. Unfortunately this cannot be reached by a simple realignment

on CAPGEN B. But in the replication service RRR, where we decide what to

do, where is no information anymore about the OLD partner A. Therefore

we need a delete segment with PARTNER_NO filled. Otherwise, your newly

created intelinkage will not work correctly.

But you can try to adapt the mobile bridge to solve the issue. Whenever

a partner is updated, just try send a DELETE segment in the first table

entry and afterwards an INSERT segemnt. This makes your interlinkage

possible (BOTH WITH SAME ROOT ID AND SO ON).

#########################################################################

I am not completely sure whether this really would be an issue because also some standard IL like CAP/CON wouldn't work...

Regards,

Wolfhard

Answers (0)