IICS best practices

• Use logical names for groups
• Use uppercase, and use underscore to separate words
• Use documented abbreviations
• Name structure: <group_logical_name>

Examples:

• ODMAS
• DCS
• BATCH_PROCESSING_AGENT_GROUP

• Name Secure Agents using logical names rather than host names
• This way agents can be migrated easily to a different host
• Use lowercase, and use underscore to separate words
• Name structure: <group>_<agent_logical_name>

Examples:

• ODMAS_test_agent
• DCS_prod_agent
• batch_processing_agent

• Use documented abbreviations and use upper case for abbreviations
• Use logical names
• Use underscore to separate words
• Generic name structure: <ConnectionType>_<logical_name>_<flag(s)>
  • Database: <db_type>_<logical_name>_<schema_name>
  • Flat File: FF_<logical_name>_<folder_name>

Examples:

• ORCL_siebel_contact_center
• FF_salesforce_lookups
• ODBC_Accounting

• Use underscore to separate words
• Include task operation in the name.
• Use consistent naming for different type of tasks
• Name structure: DSS_<SOURCE>_<TARGET>_<NAME>_(INSERT|UPDATE|DELETE)_<VERSION>

Examples:

• DSS_Salesforce_Workday_Accounts_UPDATE_01
• DSS_Salesforce_Workday_Accounts_UPDATE_02
• DSS_Coupa_SAP_Requisition_NA_INSERT

• Use underscore to separate words
• Use consistent naming for different type of mappings
• Name structure:
  • Mapping with single source: M_<SOURCE>_<TARGET>_<NAME>_<VERSION>
  • Mapping with multiple sources: M_<SOURCE>_<ENTITY>_to_<TARGET>_<NAME>_<VERSION>

Examples:

• M_CDI_Accounts_FF_incremental
• M_CDI_Accounts_Contacts_to_SFDC

• Use underscore to separate words
• Use consistent and readable(mix case) naming
• Name structure: TF_<NAME>_<VERSION>

Examples:

• TF_CDI_Acount_Contacts_to_SFDC
• TF_Hierarchy_Change_Processing

• Use underscore to separate words
• Use consistent and readable(mix case) naming
• Name structure: Schedule_<TIMEZONE>_<Frequency>_<TIME>

Examples:

• Schedule_Five_Minutes
• Schedule_PST_Daily_11PM

• See: Projects Namespace
• Name structure: {group name} – {project name}

Examples:

• DoIT-AIS-Enterprise-Integration – Salesforce Integrations

Secure Agents are licensed at a per-Secure-Agent rate. Secure Agents are installed at one Secure Agent per VM/host, or one Secure Agent per Docker Container. For more information on the cost of a Secure Agent license, please review the pricing documentation.

By running a Secure Agent, you are responsible for ensuring the availability of the Secure Agent program and its underlying VM/host. The Secure Agent program is upgraded automatically by Informatica, but you are responsible for managing/patching the underlying operating system.

The DoIT Integration Platform team has experience managing secure agents. We run our secure agent in a Docker container on Linux, hosted by Amazon Web Services (AWS). The Secure Agent Docker image is available here if you want to build and try it yourself. We use AWS Elastic Container Service (ECS) to manage the secure agent deployment environment. By allowing ECS to run the Secure Agent container, we can make sure that the Secure Agent is always running because ECS would bring up a new instance if the current instance crashed.

From our experience of running secure agents, we recommend the following when running your own secure agent:

• Reduce file system level access to the Secure Agent host: Although access to the local file system is sometimes necessary to troubleshoot integrations, we recommend avoiding using the secure agent’s file system for integrations, where possible. For integrations that deal with flat files, using Amazon S3 along with the IICS S3 connector allows an integration to use flat files without being closely tied to the underlying file system of the Secure Agent host. By using S3 instead of the Secure Agent file system, permissions and user accounts can be managed in AWS. AWS offers more self-service and automated interfaces compared to managing user accounts accounts and permissions directly in a Secure Agent host.

Avoid maintaining state in a Secure Agent host: Related to the “Pets vs. Cattle” analogy, we recommend treating Secure Agents as ephemeral components of the overall integration architecture. Accordingly, make sure configuration files and log files are stored externally to the Secure Agent host. The DoIT Integration platform team uses AWS Elastic File System to persist configuration files. By doing this, we can destroy and replace our Secure Agent container, or underlying EC2 host, with confidence that the Secure Agent will start and operate in a consistent manner.

While a single Secure Agent is most cost effective, it does introduce a risk if the Secure Agent or underlying host were to fail. By running the Secure Agent in a container platform such as AWS Elastic Container Service (ECS), you can make sure that a single Secure Agent is always running. If the Secure Agent were to crash, ECS can automatically start a new container.

This containerized single Secure Agent architecture is appropriate for scheduled ETL jobs, but event-driven integrations, such as integrations built on Cloud Application Integration (CAI), have different requirements. For event-driven integrations, we recommend running at least two Secure Agents in parallel. If one Secure Agent were to crash, the other would be able to handle requests while a new Secure Agent is brought up.

For more information on Secure Agents with Cloud Application Integration, please see this documentation from Informatica.

You have multiple options if you are looking for a Secure Agent for training and learning purposes.

• Install a Secure Agent in your local computer for training and learning proposes. See installation guide for installing Secure Agent locally.
• Use Docker image maintained by EI for installing Secure Agent locally. See documentation (mentioned under Recommendations above as well).

Test Secure Agent instance deployed by EI on AWS. See user guide for details.