From the code side, I think supporting a new type of widget requires changes in both the code and in a config file.
Seems like it could all be done in a config file, but maybe it’s not an issue since these don’t change very often.

In the code, need to add PNF (assuming that’s what it’s called in the csar?) to this “mandatoryElements” list in:
onap_babel/src/main/java/org/onap/aai/babel/xml/generator/model/WidgetType.java:

private static final List<String> mandatoryElements = Arrays.asList( //
"SERVICE", "VF", "VFC", "VSERVER", "VOLUME", "FLAVOR", "TENANT", "VOLUME_GROUP", "LINT", "L3_NET",
"VFMODULE", "IMAGE", "OAM_NETWORK", "ALLOTTED_RESOURCE", "TUNNEL_XCONNECT", "CONFIGURATION", "CR", "INSTANCE_GROUP");

That list defines all the widget types that we will pull over to ANAI.
These get translated to our node-types and model-ids in the Kubernetes config stuff (here’s our ecomp one):
aai-ecomp-controller/kubernetes/aai/components/aai-babel/config/tosca-mappings.json

That is where they define a one-to-one mapping between the above things like "VF" or "LINT" and the AAI names like "generic-vnf" or "logical-interface" as well as the "modelVersionId" an "modelInvariantId" to use for each one. The mapping is in the "widgetTypes" section.

There is also a "widgetMappings" which maps some ambiguous names to one of the basic widgetTypes. This does not seem to be required for all
widget types. Probably don’t need to change that for PNF, but it would depend on what PNF’s can look like in the CSAR file.