But what is the trouble?
When you push the data from inc to pbm, it was not recorded? You can see the data on ur db?
Make sure the field is not display type, on databasefield prop.
I think you first need to understand what the system is doing and why certain Filters are firing.
- When you create an relationship from one request to another, there are 2 records created in the associations form (one for each direction) which then holds the relationship data between the 2 requests
- This is a very limited set of data that is used to display the relationship in the Relationship Tab/Table that is pushed to the associations records
This is what the Filters you have found are doing. These do not push custom fields around the system, they just create the required records to display the relationship between the 2 requests (x2 association records) and push to the associations form.
If you want to push data between the records, then you need to know what the request ID is that you want to target and/or create the relationship record first before pushing your data around (or the user would not know where the data went).
You can also see what is happening via the Filter logs, which in all cases should be your first point to look at to understand what the system is doing.
Capture Active link logs along with Filter in User Preference form, relogin and perform the same action. You will get all the details.
1 of 1 people found this helpful
you didn't mention whether your test resulted in custom field on Problem console populated by data from incident or not; I would have expected it not to, especially when creating relationship instead of related request, but your second sentence sounds like it did -- if that is the case, do you wish to avoid replication, or if it isn't, do you wish to enforce replication but do not want to add your own workflow element with push fields action?
Push fields action is available in active links as well, so I'd suggest to start by activating logging of active links and filters in AR System User Preference for your test user, log in (again) as that user, open incident you wish to relate to problem, change contents of your custom field, click on Create Relationship to > Problem investigation, select problem you wish to relate incident to, but before clicking Relate, clear log window contents to capture contents of log window from that point on until appearance of popup informing you that relationship has been created into text file (copy-paste should suffice) for easier analysis.
What you got should be complete record of actions (active links and filters) taken to relate incident to problem (investigation). Among those, you should find active link INT:HPDPBM:PIS:Associate_HPD_180_SubmitHPDAssoc containing push fields action which creates association in HPD:Associations, and PBM:PIS:Associate_200_SubmitInvestigationAssoc containg push fields action which creates association in PBM:Investigation Associations.
You could execute similar procedure for Create Related Request > Problem Investigation, which would actually copy some data from Incident into Problem Investigation (e.g. by using Run Process action in active link(s) INT:HPDPBM:INC:CreateAssociation_Investigation_003_NoResolution/WithResolution/WithResolutionCate/WithResolutionProdCate, one of which later "causes" creation of Problem Investigation via open window action in active link SHR:LHP:FormOpenCreateAssocPBI_InVF).
Thanks a ton for writing such a detailed elucidation
I was caught up with some other work today but would certainly try this out first thing tomorrow morning.
Thanks for responding, Ganesh.
Planning to do this tomorrow.
Thanks for responding.
You have given me a lot of fodder for thought.
I need to mull over before I can send you a rejoinder.
Thanks for taking interest.I did not think about fiddling around in DB but let me try a few other things before I do this first.
1 of 1 people found this helpful
Just one question, Ganesh - Should I enable server side filter logs too while following your above mentioned suggestion?
Please don't mind if I ask a minor question.
While I enable AL and FLTR logging from User Preference form, should I enable filter logging from the server side also?
Thanks a lot again for explicating in such great depths
Enabling filter logging in User Preference form activates client-side logging equal to (but separate from) server-side filter logging limited to workflow initiated by active user so it doesn't matter whether both are on, or only the client-side one is; it is probably best to leave server-side logging set as it normally is and use client-side logging for troubleshooting.