Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Current »

KFS Modules

Modules in KFS are high-level areas of functionality. The key interfaces and classes that represent this concept in code are...

  • org.kuali.kfs.sys.FinancialSystemModuleConfiguration
  • org.kuali.kfs.sys.service.impl.KfsModuleServiceImpl

And, the core services that provide access to the module definition and module-related data and logic are...

  • org.kuali.rice.kns.bo.ModuleConfiguration
  • org.kuali.rice.kns.service.ModuleService
  • org.kuali.rice.kns.bo.ExternalizableBusinessObject

Modules are used to classify parameters. KFS has 5 core modules and more optional modules. When a module configuration is defined in can list the externalizable business objects so that others modules could get handle to them.

Sample module configuration, usually this is specified in module specific spring file org\kuali\kfs\module\<module-name>\spring-<module-name>.xml

org.kuali.kfs.module.cam.spring-cam.xml
<bean id="camModuleConfiguration" parent="camModuleConfiguration-parentBean" />

<bean id="camModuleConfiguration-parentBean" class="org.kuali.kfs.sys.FinancialSystemModuleConfiguration" abstract="true">
    	<property name="namespaceCode" value="KFS-CAM" />
	<property name="initializeDataDictionary" value="true" />
        <property name="packagePrefixes">
            <list>
                <value>org.kuali.kfs.module.cam</value>
                <value>org.kuali.kfs.integration.cam</value>
            </list>
        </property>
        <property name="externalizableBusinessObjectImplementations">
            <map>
                <entry key="org.kuali.kfs.integration.cam.CapitalAssetManagementAsset" value="org.kuali.kfs.module.cam.businessobject.Asset" />
                <entry key="org.kuali.kfs.integration.cam.CapitalAssetManagementAssetType" value="org.kuali.kfs.module.cam.businessobject.AssetType" />
            </map>
        </property>
		<property name="dataDictionaryPackages">
			<list>
                <value>org/kuali/kfs/module/cam/businessobject/datadictionary</value>
                <value>org/kuali/kfs/module/cam/document/datadictionary</value>
			</list>
		</property>
		<property name="databaseRepositoryFilePaths">
			<list>
				<value>org/kuali/kfs/module/cam/ojb-cam.xml</value>
			</list>
		</property>
		<property name="jobNames">
			<list>
				<value>assetDepreciationBatchJob</value>
			</list>
		</property>
		<property name="fiscalYearMakers">
          <list>
            <ref bean="assetObjectCodeFiscalYearMaker" />
          </list>
        </property>
	<!-- Asset Depreciation batch - START -->
	<property name="triggerNames">
		<list>
			<value>assetDepreciationBatchJobTrigger</value>
		</list>
	</property>
	<!-- Asset Depreciation batch - END -->
	<property name="batchFileDirectories">
         	<list>
            	<value>${reports.directory}/cam</value>
            	<value>${staging.directory}/cm</value>
          	</list>
        </property>

</bean>

Now let us try to understand key parts of this configuration,

namespaceCode - used by system to identify the module name space and very useful in parameter name resolution and KIM name space resolution.

externalizableBusinessObjectImplementations - when a BO is exposed outside the scope of specific module then it should offer an integration package and respective interface that can by accessed by external modules. So here the definition of exposed interfaces and their concrete implementation are listed.

jobNames- lists down the batch jobs available with the module.

triggerNames - trigger configurations used by quartz when it is enabled in the application. A sample is here

<bean id="assetDepreciationBatchJobTrigger" parent="cronTrigger">
	<property name="jobName" value="assetDepreciationBatchJob" />
	<!--  it will run on therd=3 thursday=5 of the month-->
	<property name="cronExpression" value="00 00 00 ? * 5#3" />
</bean>

Mavenization

As of release 6, Maven provided KFS with an easy path with a first, small step towards a microservice architecture.  Each of the optional modules has moved to its own Maven module, which exist as separate directories under the root directory, each with its own POM.  All of the core modules currently live in a single Maven module: kfs-core.  Finally, web artifacts for all modules are collected in a single, separate Maven module: kfs-web.  The one exception is that both of the optional modules, KFS-CAM and KFS-CAB, have been joined into a single Maven module, kfs-cam.  It is anticipated that in the future, KFS-CAM and KFS-CAB will be joined into a single KFS module as well.

This restructuring in KFS obviates the need for the check modularization tests - in their own Maven modules, each optional KFS module can only access the code to modules which it has a declared dependency on.  Those dependencies are then declared in the Maven pom for each KFS/Maven module - thereby making the dependencies among optional KFS modules self-documenting.  In addition to being declared in the pom for the module, each module also includes its own set of run-time properties which are used by unit tests, and that set of properties - found in the module's src/test/config directory under the name of kfs-{module}.properties - has a spring.source.files property which is used by the process to run just that module's unit test suite.  The main module spring source file for each dependent module must be pulled in via that file.

For instance, let's look at the kfs-ec module.  In the pom for kfs-ec, we find that it's dependent on kfs-core and the core tests, as well as upon the kfs-ld and kfs-cg modules:

from kfs-ec/pom.xml
<dependencies>
  <dependency>
    <groupId>org.kuali.kfs</groupId>
    <artifactId>kfs-core</artifactId>
    <version>${project.version}</version>
  </dependency>
  <dependency>
    <groupId>org.kuali.kfs</groupId>
    <artifactId>kfs-cg</artifactId>
    <version>${project.version}</version>
  </dependency>
  <dependency>
    <groupId>org.kuali.kfs</groupId>
    <artifactId>kfs-ld</artifactId>
    <version>${project.version}</version>
  </dependency>
  <dependency>
    <groupId>org.kuali.kfs</groupId>
    <artifactId>kfs-core</artifactId>
    <version>${project.version}</version>
    <type>test-jar</type>
    <scope>test</scope>
  </dependency>
</dependencies>

And then, in src/test/config/kfs-ec.properties, we find the spring files for LD and CG pulled in:

from kfs-ec.properties
spring.source.files=classpath:spring-kfs-imported-rice-beans.xml,classpath:spring-additional-rice-beans.xml,classpath:org/kuali/rice/core/CommonSpringBeans.xml,classpath:kfs-cache-config.xml,classpath:org/kuali/kfs/sys/spring-sys.xml,classpath:org/kuali/kfs/coa/spring-coa.xml,classpath:org/kuali/kfs/fp/spring-fp.xml,classpath:org/kuali/kfs/gl/spring-gl.xml,classpath:org/kuali/kfs/pdp/spring-pdp.xml,classpath:org/kuali/kfs/vnd/spring-vnd.xml,,classpath:spring-kfs-batch.xml,classpath:org/kuali/kfs/integration/spring-integration.xml,classpath:org/kuali/kfs/module/ec/spring-ec.xml,classpath:org/kuali/kfs/module/ld/spring-ld.xml,classpath:org/kuali/kfs/module/cg/spring-cg.xml
spring.test.files=classpath:org/kuali/kfs/sys/spring-sys-unit-test.xml,classpath:org/kuali/kfs/sys/spring-sys-test.xml,classpath:org/kuali/kfs/gl/spring-gl-test.xml
property.files=classpath:org/kuali/rice/krad/ApplicationResources.properties,classpath:org/kuali/rice/krad/KRAD-ApplicationResources.properties,classpath:org/kuali/rice/kew/ApplicationResources.properties,classpath:org/kuali/rice/ksb/ApplicationResources.properties,classpath:org/kuali/rice/kim/ApplicationResources.properties,classpath:org/kuali/rice/krms/ApplicationResources.properties,classpath:org/kuali/rice/core/web/cache/CacheApplicationResources.properties,classpath:org/kuali/kfs/coa/coa-resources.properties,classpath:org/kuali/kfs/fp/fp-resources.properties,classpath:org/kuali/kfs/gl/gl-resources.properties,classpath:org/kuali/kfs/pdp/pdp-resources.properties,classpath:org/kuali/kfs/sys/sys-resources.properties,classpath:org/kuali/kfs/vnd/vnd-resources.properties,classpath:org/kuali/kfs/module/ec/ec-resources.properties,classpath:org/kuali/kfs/module/ld/ld-resources.properties
 

Together, these overrides allow the unit tests to pull in all the beans necessary to successfully run kfs-ec's unit test suite.  kfs-ec produces a jar in turn, which can be used as a dependency for other modules.

 

 

Kuali documentation is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License. 

Kuali software is licensed for use pursuant to the Affero General Public License, version 3.

 Copyright © 2014 Kuali, Inc. All rights reserved. 

Portions of Kuali are copyrighted by other parties as described in the Acknowledgments screen. 

Kuali ® is a registered trademark of the Trustees of Indiana University.

  • No labels