Java CAPS 5.1.x Best Practices

1. Architecture: Layered architecture is used to make services loosely coupled and most interactions occur only between neighboring layers in a distributed network. The layers include receiving layer, mapping layer, delivery layer and services layer.

• Receiving Layer: Receives data from an INBOUND external system
• Mapping Layer: Transforms the input message in to required output format. All validations, business rules are applied in this layer
• Delivery Layer: Delivery layer sends data to OUTBOUND external system
• Services Layer: A layer used to process interface alerts, logs and errors to a common database

Any changes to business requirements (code) will affect the mapping layer alone where the business transformations are implemented. Also during the runtime, services can be deployed depending on the location of external systems.

2. Reusable Web Services: Functional re-usability is preferred over code re-usability. Common business functions can be converted in to reusable web services. Ex: We can have re-usable services for some of the common functions like FTP’eing files, Sending/Receiving IDOCs to/from SAP etc, Sending emails to stake holders.

3. Data Streaming: Streaming is used to process files with large sizes. This will avoid any performance degradation while transforming large files. While processing large data coming from database/file (multiple XML/IDOC records), it is better to process one record at a time. Processing the complete data at once will pose performance issues and also require more system resources.

4. Variables & Constants: Using project or environment variables/constants provide flexibility to deploy projects/environments between environments. The project or environment variables/constants defined can be used as multitude of fields in project components (connectivity map) and environment components (Integration Server, IQ Manager, External Systems etc). This makes easy for deploying projects on multiple environments and only environment variables will be changed from one environment to other and there is no need to change the configurations on project connectivity maps.

5. Distributed Runtime Deployment: Services can be deployed based on the location of end systems. This will avoid any network traffic/failures between external systems and eGate system. In case of connection failures to external systems all the messages are queued in the JMS queues and processed after they become operational.

6. Common Services Framework (CSF): This is used to send alert, logging and error notifications to a common database. The data will be used to alert teams with emails in case of data or connection failures. The framework will automatically captures required information (project name, service name etc) to send alert, log and error details to CSF database. This can also be extended by having services like sending alerts to technical teams etc. Each of these services can be created as self contained projects and deployed in a distributed network.

7. Self contained project: Most of the times, projects have dependencies with some common project services (that contains re-usable JCDs etc). But wherever applicable, it is suggested to avoid dependencies/references on/to other projects/sub-projects. This makes code deployments simple. This is not going to have any impact on the runtime performance.

8. Reusable JARs: It is suggested to use reusable JAR files for common methods/functions which are reused across the projects ex: Date/String manipulations, Number/Date Validations etc. This will also increase the runtime performance of the interfaces.

9. Property Files: Using property files will make deployments easy between environments. Ex: SAP control parameters might be different in different environments. Hard coding this in either JAR files or code will make difficult to handle the changes.

10. Logs Levels: Logs can often degrade the performance of eGate system (integration server). It is very important to have the optimum logging levels to report errors & alerts. It is recommended to have debug level.

11. Error Reporting: While reporting errors, it is important to give enough information on the nature of the error (data/system, recoverable/non-recoverable exceptions). Basically the information in the error need to provide

• The data/system error that is causing the error
• Operation Performed (Date/String Manipulation)
• Value of the data that is causing the problem

Tools like Common Service Framework automatically captures data like project name, service name, date/time stamps etc.

12. Exception Handling: Exceptions can be classified in to two types recoverable and non-recoverable. Recoverable exceptions can be processed once the data or system/connection issues are fixed or recovered (Ex: FTP server is unavailable to send data file). Non-recoverable exceptions cannot be processed and must be gracefully consumed. The exception details must be reported to CSF or some error database with the information that can be understandable to both business and technical teams (Ex: Parser/Unmarshal, JMS Exceptions etc).

13. Performance: Performance of the system can be improved by deploying services on a distributed network and make them communicate with each other. It is observed that multiple projects deployed on multiple integrations servers will provide a better system performance as the load is share across multiple integration servers. It is also recommended not to have more than 15 projects deployed on one domain. Having more than 15 projects leads to degradation of system performance and also more number of files are opened by IS which leads to exceptions that cannot be rectified using system configurations.

14. Fine Tuning Runtime Objects: It is important to fine tune certain runtime objects like Integration Server, JMS etc for optimal system performance. The integration server JVM parameters can be tailored to efficiently process the messages (Ex: Heap Size, Log Levels etc). Also JMS queues can be configured with maximum size of the messages. By default the heap size of integration server is set to 512 MB which is good enough to process messages. If more number of projects are deployed on the same integration server, it is suggested to have more heap size on the Integration server (-Xmx). This can be configured in asadmin. Ex: http://<logical-host-server>:<domain-base-port>/asadmin.

15. Parallel Testing Environments: It is Java CAPS feature that one project can be deployed on to one or more environments. It is possible to have multiple JCAPS testing environments on one server, provided they are uniquely identified by their domain base port numbers. Having parallel testing environments on one server will reduce the cost of EAI infrastructure and maintenance.

16. OTD Best practices

Data Base OTD

• Stored Procedures/Prepared statements are preferred to perform database operations like select, insert, update and delete. Since they are pre-compiled, they will give optimum performance during runtime.

17. Collaboration Rule Best Practices

• Use Java coding standards to name the variables, constants, methods.
• Use methods which return some object other than void
• Use a StringBuffer object in place of a String object when doing concatenations
• Close the open connections when you are done with the FTP operations.
• While publishing the data into the JMS topic/queue, it is suggested to keep data size less than the DBS segment size to avoid JMS failures. It is observed that messages are consumed and lost with out giving a clue in the logs as the message size is larger than queue size. Often verify stcms.log file, when a message is lost.
• Use Database batch updates/insertions/deletions. Also for each operation, an integer is returned that explains the number of records affected. The value must be captured as certain database operations provide no information when updation/deletion is not affected due to data issues.
• Logger Object used for logging the information must be precisely used. Debug is used by default. But it is recommended to use fatal for logging exceptions.
• Comments must be in detailed for each variable, constant, method used in the collaboration rules. This is very important practice on a maintenance perspective.

18. Connectivity Map Best Practices:

It is suggested to have one connectivity map per service layer (receiving, mapping and delivery). This will allow deploying each layer independently in a distributed network. Ex: Receiving Layer can be deployed in location A where it receives the data from external system that is residing in location A. Delivery layer can be deployed in location B where it sends data to external system that is residing in location B.

19. Processing Special Characters: JCAPS is incapable of processing certain special characters like Pound Sterling (£). It is automatically converted to Pound (#) before the data is sent to external system. Currently users are requested to enter GBP for pound symbol. We may either encypt/depcrypt or encode/decode the data to resolve this issue. This is a learning as well.

20. System Housekeeping and Cleanups:

1.Steps for eManager cleanup

• Make sure the eManager is STOPPED.
• Backup and delete the EventRepositoryDb.backup, EventRepositoryDb.data from emanager/EventRepositoryDb
• Edit the EventRepositoryDb.script from the emanager/EventRepositoryDb folder and delete the following lines:

SET TABLE NOTIFICATION_EVENT INDEX 984 17

SET TABLE MSG_CODE_ARGS INDEX -1 0

• Restart eManager after any of the above cleanup has been performed

2.Steps for Repository cleanup

• Make sure the repository is STARTED.
• Remove the locks for all the users by using the repository utility <cleanupworkspace>. This will remove any open locks and release the repository runtime resources.
• Make sure the repository is STOPPED.
• Remove the files under $repository/server/temp

3.Steps for domains cleanup

• Make sure the domain is STOPPED.
• Delete the folder $logicalhost/is/domains/<domain-name>

21. System Security: It is suggested to provide restricted access to users when multiple projects/users are working in groups. ACL can be applied against users to disable the access to rest of the projects which are not applicable to them. This also reduces the risk of accidental editing, deletions to the project objects.