This section provides information about the SPI approach and how adapters are packaged and derived at runtime based on current entity and domain under consideration.

Service Provider Interface (SPI) is an API intended to be implemented or extended by a third party. It can be used to enable framework extension and replaceable components.

• 
  Description of the illustration link1.png

• 
  Description of the illustration link3.png

All the external facing adapters will be loaded using SPI.

Benefits of SPI:

• No database entries are required.
• No need of adapter factories.
• Can add adapters at run-time.
• Provides the list of available implementations from which we can use the best suited one.

In this approach adapter is selected using the following call.

ExtxfaceAdapterFactory.getInstance().getAdapter(Interface.class, "method", DeterminantType);

Here,

• ‘Interface.class’ is object of interface implemented by the host (external system) adapter.
• ‘Method’ is name of method which we are intended to call of that adapter.
• DeterminantType is determinant type of the domain from which this call is made.

Sample code is as follows:

Adapter configuration:

For adapter configurations, the preference ExtxfaceAdapterPreference is used. This preference contains Entity as key and External System (Host Name + Version) as value. So we can use select external systems (Hosts) on the basis of entity. E.g. For entity 000 we want to use UBS 12.4 and for entity 001 use OBP 2502 then the entries will be

We can also give multiple External System separated by comma “,” for an entity, and then adapter will get selected on the basis sequences of external systems given in value.

E.g. if the value is UBS12.4,BI1.0 then first implementation is searched in UBS 12.4 jar if is not found then it will look in BI1.0 jar.

Adapter Registration:

After adding adapter java file in project it need to be register as provider. To register your service provider, create a provider configuration file, which is stored in the META-INF/services directory of the project. The name of the configuration file is the fully qualified class name of the service provider(interface implemented by adapter), and file content which is fully qualified name of the adapter class.

How will system derive adapter?

In the external system interface implementation project like (com.ofss.digx.extxface.ubs124.impl), inside src/META-INF folder, we will have a MANIFEST.MF file inside which we will define the following attributes:-

Implementation-Title: UBS

Implementation-Version: 12.4

It will tell us that the adapters are for external system UBS 12.4. While adding a new interface implementation project, we need to create MANIFEST.MF file too, defining implementation title and version.

While calling an adapter, we provide three parameters 1. Interface class name 2.method name 3.determinant type(for particular domain class).

Determinant type for particular domain class (digx_me_entity_determinant_b).

We match determinant type to market entity, then business unit and then legal entity.

On the first match, we derive the external systems using ExtxfaceAdapterPreference explained above. Then we derive external systems corresponding to others(lower order ones). Thus we have a list(list 1) of external systems in order.

For example, if 1st match is market entity. Then we will have external systems corresponding to entries for market entity, then business unit and finally legal entity if entries are found.(in order).

If 1st match is business unit, then we will have external systems corresponding to entries for business unit and legal entity if found(in order).

Here in the diagram above, for domain class ConfigVarBDomain, determinant_type is BNU(business unit). lets suppose corresponding determinant value is 000.

Now, for prop_id=000, it will fetch extsystems as UBS12.3,ipm1.0.

Now for legal entity(LGE), lets suppose corresponding determinant value is 001. so it will fetch external system as TP1.0.

So we have external system list (list 1) as {UBS12.3,imp1.0,TP1.0};

Also If none matches, we derive external system corresponding to enterprise. for eg. for enterprise, lets suppose corresponding determinant value as 01. so external system list(list 1) will be {UBS12.4,ipm1.0}.

How the adapters are loaded:

Now we will load all those adapter classes, that will implement the interface whcih we get as first parameter. Now we will maintain another list or map (list 2) of external systems to adapter, that we will resolve from all those adapter classes. (How will system know that a adapter belongs to which external system or host?).

We will iterate through list 1(list of external systems that we got from preference entry) in order. When we find the first matching external system in list 2, we will return the corresponding adapter.

For example, we iterate through list 1 : {UBS12.3,imp1.0,TP1.0}. it will first find if loaded adapter class contains adapter that belongs to external system UBS12.3. then it will retun that adapter. if not found, it will search if any loaded adapter class belongs to imp1.0. if found it will return that adapter. if not, then it will similarly go for TP1.0.

How to override an adapter?

One can enter (interface class name + ''."+ method name or only interface class name) in ExtxfaceAdapterPreference against which one can specify the adapter that one want to be overriden by.

E.g.

Insert into digx_fw_config_all_b
(PROP_ID,CATEGORY_ID,PROP_VALUE,FACTORY_SHIPPED_FLAG,
PROP_COMMENTS,SUMMARY_TEXT,CREATED_BY,CREATION_DATE,LAST_UPDATED_BY,
LAST_UPDATED_DATE,OBJECT_STATUS,OBJECT_VERSION_NUMBER,EDITABLE,CATEGORY_DESCRIPTION)
values (<Fully qualified adapter interface name>,'extxfaceadapterconfig', 
<Fully qualified adapter implementation  name>,'N',null,'','ofssuser', 
 sysdate,'ofssuser',sysdate,'Y',1,'N',null);

sample:

Insert into digx_fw_config_all_b
(PROP_ID,CATEGORY_ID,PROP_VALUE,FACTORY_SHIPPED_FLAG,PROP_COMMENTS,SUMMARY_TEXT,CREATED_BY,
CREATION_DATE,LAST_UPDATED_BY,LAST_UPDATED_DATE,OBJECT_STATUS,OBJECT_VERSION_NUMBER,EDITABLE,
CATEGORY_DESCRIPTION)values ('com.ofss.digx.app.loan.adapter.
ILoanAccountAdapter','extxfaceadapterconfig',
'com.ofss.digx.extxface.loan.impl.LoanAccountMockAdapter','N',null,'','ofssuser',
sysdate,'ofssuser', sysdate,'Y',1,'N',null);