I have written this blog post to document the solution I recently implemented to meet a specific requirement, in the hope that it will help others with similar requirements. The solution took a bit of time to get to as finding the root cause of errors in the UI Designer can be tricky, so hopefully documenting some of the pitfalls and how they were overcome will be useful.
A custom BO is created from an Opportunity on the Activities tab. The Opportunity ID is passed to the QC screen to create the custom BO linked to the Opportunity. The requirement is for the customer lookup on the QC screen to only bring back customers that are Involved Parties of the Opportunity.
The embedded component for the custom BO (Project Request) has been added to the Activities tab within the Opportunity and the New button calls the QC screen for this BO.
The Quick Create screen is shown below. The Customer field is the one that requires a custom lookup to only show Involved Parties of the linked Opportunity.
First I created an OVS based on the Opportunity BO.
When opening the OVS in the UI Designer, the first thing to do was delete the standard query and create a SADL query. This can be done by right clicking on the query and deleting and then right clicking on the Queries folder and clicking Create New SADL Query.
The key thing here is that by deleting the standard query and creating a new one it will create a new event handler and clear the query on the existing event handlers so you need to amend these as below, otherwise you will get errors when launching the OVS.
Check the properties of the defaultset query and set the OnSelect event to call the GetValueHelpHandler
Amend the existing event handlers to use the new SADL query
I set the query parameters as below using the Party node. Originally I wanted to use the ExternalParty association, however this doesn’t work and results in SADL query generation errors (the downside of using the Party node is that all sales team parties are also returned so have to be filtered out by the query).
Note that the ID at the root level is not used as a selection parameter but the ID in the ToParent association to the Party node. If the ID of the root is used then you will only get one entry returned, rather than all the involved parties. Note also that the PartyUUID is also selected as result parameter, as passing the PartyID back via the Outport did not work in my scenario (this will be shown later).
The Basic Find indicator is set for PartyID and FormattedName as this allows the user to search by number of name using the SearchText field.
I want the query to be based on Opportunity ID so this is passed into the QC on the Inport. An event is fired on initialisation to assign the ID to the query search parameters.
The data model now looks like this:
Because the Party node returns all parties linked to the Opportunity (both external and the sales team) I needed a way to filter out the sales team. To do this I decided on using the PartyTypeCode and created two defaultsets, one to query 147 – Partner and one for 159 – Account. The RoleCode could also be used for this. Remember when creating new defaultsets to change the eventhandler triggered to GetValueHelpHandler!
Now for the Designer. On the AdvancedListPane, the defaultsets need to be assigned as below:
Note that when changing between the defaultsets the query was losing the ID search parameter, so I added the below assign DataOperation to the GetValueHelpHandler to set the ID each time the defaultset is changed.
The columns in the AdvancedListPane also need to be bound to the correct field in the data model:
Finally the Outport needs to be amended to bind the UUID and Name to pass these back to the field on the QC.
Now the OVS is linked to the field on the QC and the Opportunity ID field is bound as below:
So lets see it working:
These are the Involved Parties of the Opportunity
This is the OVS on the QC customer field