Interfacing with KFS Types of Interfaces From Stores to KFS KFS reference data retrieval Data push into KFS Updating of PURAP Data? Creation of KFS documents? Ledger Entries From KFS to Stores Notification of PURAP operations Lookups/Inquiries (if a stores attribute (e.g., order number) is rendered on any PURAP documents To/From Rice Server RiceApplicationConfigurationService Action List/Document Search/KIM Type Services Interfacing with KFS Create DTO objects for KFS data which we want to pull from KFS. Examples: AccountDTO ChartDTO ObjectCodeDTO Should contain a subset of the properties from the comparable objects in KFS. Should use a KFS package structure. These objects will need to live in KFS eventually. Use org.kuali.kfs.external.coa.dto for now Create a ChartOfAccountsExternalService in KFS API methods like: AccountDTO getAccount( chart, account ) Call established KFS services (obtain via SpringContext) Use org.kuali.kfs.external.coa.service Create a FinancialSystemReferenceDataService in EXTMM Should obtain the service below from a service locator Implement API methods which match the KFS service methods Additional convenience methods which combine KFS calls? Interfacing with KFS KFS will need its build process modified to be able to build a service export JAR file which can be used by other applications. Well have to fake this for now. Define this package structure in the stores project under a different source tree. Export the classes in the org.kuali.kfs.external packages unless they are in an embedded impl package. This may move into the integration package, but I dont think everything in there can live without core KFS objects. The non-implementation classes in this package will need to. Updating KFS Data Create an external interface for KFS. Also need to create DTO objects for any complicated parameters. (Order information/customer information/vendor information) Implement against the KFS services as-is if possible Create a companion service in EXTMM. KFS Updating EXTMM Data If there are occasions where KFS will need to notify EXTMM of an action: KFS will need to be patched to make a service call from the appropriate location to a StoresUpdateService (also in the patch) Again, this interface needs to not depend on ANYTHING in the actual KFS module. All methods should use DTOs defined in the same package area. The StoresUpdateService would be in the external package for PURAP. (?) The patch would also include a default implementation (and associated configuration) for this service with an empty implementation. KFS Updating EXTMM Data (2) EXTMM would provide an implementation, exposed on the KSB, of that StoresUpdateService with the same name used by KFS. EXTMM implementers will have to modify the KFS configuration to comment out that default implementation to force the KSB to scan the bus for the service deployed by EXTMM. How many interfaces? For ease of implementing, there should be one external service per KFS module. Unlessthere is a significant collection of related methods to expose. But, all reference data for a module could be exposed via a single service.