If you are not yet familiar with this feature, you are missing out. Go read about it:
https://docs.microsoft.com/en-us/dynamics365/unified-operations/dev-itpro/extensibility/method-wrapping-coc
There was one significant restriction applied (by design) to these wrapper methods:
Wrapper methods must always call next
Wrapper methods in an extension class must always call next, so that the next method in the chain and, finally, the original implementation are always called. This restriction helps guarantee that every method in the chain contributes to the result.
However, what this resulted in is a more complex implementation and "workaround-like" solutions in standard code to enable some of the commonly requested extension points, where the ISV/VAR would like to completely replace the standard logic with an alternative implementation that does the same or a very similar operation.
With Platform update 11 we have added a new attribute, which allows Microsoft (on request from multiple partnres), where it is justified, to decorate a particular protected or public method, allowing wrapper methods to not call next on it, replacing the logic of that method.
Here's how it looks:
///
/// Attribute used to enable or disable replacing a method in an extension class.
///
///
/// Private methods can not be set to be replaceable even with the usage of this attribute.
///
public class ReplaceableAttribute extends SysAttribute
{
boolean isReplaceable;
public void new(boolean _isReplaceable = true)
{
super();
this.isReplaceable = _isReplaceable;
}
}
Example
OK, let's now look at an example of how this will be used.Note. Since the attribute only appeared in PU11, that means that all application released up to and including Spring release 2017 do not have any methods marked with this attribute. It is only now with the Fall release of 2017 that you might see some methods being tagged this way.
Say, an ISV wanted to provide an alternative implementation for looking up Warehouses on a specified Site, more specifically, for the method InventLocation.lookupBySiteIdAllTypes().
One way to solve this could be to add a delegate, invoke it at the beginning of the method, and then check the EventHandlerAcceptResult to see if someone has replaced the implementation, in which case, short-circuit the method execution, so standard logic is not executed.
A potential implementation shown below:
public class InventLocation extends common
{
public static void lookupBySiteIdAllTypes(FormStringControl _ctrl, InventSiteId _inventSiteId)
{
EventHandlerAcceptResult lookupBySiteIdResult = EventHandlerAcceptResult::newSingleResponse();
InventLocation::lookupBySiteIdAllTypesDelegate(_ctrl, _inventSiteId, lookupBySiteIdResult);
if (lookupBySiteIdResult.isAccepted())
{
return;
}
SysTableLookup sysTableLookup = SysTableLookup::newParameters(tableNum(InventLocation), _ctrl);
ListEnumerator listEnumerator = List::create(InventLocation::standardLookupFields()).getEnumerator();
while (listEnumerator.moveNext())
{
sysTableLookup.addLookupfield(fieldName2id(tableNum(InventLocation), listEnumerator.current()));
}
sysTableLookup.parmQuery(InventLocation::standardLookupBySiteIdQuery(_inventSiteId));
sysTableLookup.performFormLookup();
}
}
Lookups is one of the common examples, where people might was a complete replacement of the standard logic. Note that by definition that means only one of the ISV solutions can replace it. If two attempt to accept() the result, an error will be shown.
That would typically mean that a logical conflict exists between the two ISV solutions, and the VAR would need to decide which ones to use, or make it configurable somehow.
Now, let's try to see what could be done with the new attribute, if Microsoft were to apply it on this method.
public class InventLocation extends common
{
[Replaceable]
public static void lookupBySiteIdAllTypes(FormStringControl _ctrl, InventSiteId _inventSiteId)
{
SysTableLookup sysTableLookup = SysTableLookup::newParameters(tableNum(InventLocation), _ctrl);
ListEnumerator listEnumerator = List::create(InventLocation::standardLookupFields()).getEnumerator();
while (listEnumerator.moveNext())
{
sysTableLookup.addLookupfield(fieldName2id(tableNum(InventLocation), listEnumerator.current()));
}
sysTableLookup.parmQuery(InventLocation::standardLookupBySiteIdQuery(_inventSiteId));
sysTableLookup.performFormLookup();
}
}
The ISV can now in his model wrap this method in an augmentation class, provide his own implementation, and avoid calling next():
Important.
We recommend to always make the call conditional, so that your own logic that is not calling next is only invoked for your specific case. This will make you a good citizen, that can co-exist with other ISV solutions also wrapping the same method.
[ExtensionOf(tableStr(InventLocation))]
public final class MyPU11InventLocationTable_Extension
{
public static void lookupBySiteIdAllTypes(FormStringControl _ctrl, InventSiteId _inventSiteId)
{
const str MySpecialWarehouseCtrlName = 'MySpecialWarehouseCtrl';
if (!_inventSiteId || _ctrl.name() == MySpecialWarehouseCtrlName)
{
// Your own logic
_ctrl.performTypeLookup(extendedTypeNum(InventLocationId));
}
else
{
next lookupBySiteIdAllTypes(_ctrl, _inventSiteId);
}
}
}
Pretty easy and neat, huh?
Missing an extension point? Log it!
Again, remember, that in order to skip calling next, the method needs to be marked by Microsoft as Replaceable.If you need a particular method to be Replaceable, or if you in general need an extension point that is not available in the latest available release, please follow the instructions outlined here to create an extensibility request for us.
Links
To review the list of features included in Platform update 11, see the What's new or changed topic and refer to the KB article for details about the customer found bug fixes included in this update.
No comments:
Post a Comment
Please don't forget to leave your contact details if you expect a reply from me. Thank you