How to get access to Informatica Intelligent Cloud Services (IICS), and understand the basics of how to use at UW-Madison for data integrations.
The EI Integration Team has developed an Integrator Training Canvas course that is the recommended way to learn about integrations and the IICS iPaaS offering. The Canvas course is an online, self-paced, eight-module course that covers the basics of the integration ecosystem here at UW-Madison. The first five modules of the course are relevant to anyone with an interest in integrations, including decision makers, managers, and integrators. The remaining three course modules are a hands-on walkthrough to building at least two complete end-to-end integrations using IICS.
Request Access
Someone will get back to you within 3 business days with next steps, including instructions to get access.
Depending on your use case, we might schedule a meeting to discuss your use case further and decide on next steps.
Once you have access
The Integration Platform team will give you access to IICS, and help address additional connectors, sub-orgs, or secure agent licenses, if applicable. Costs may be involved with secure agents or sub-orgs.
Access
User access is controlled through Manifest.
Next steps
After getting access to IICS, you can start training, follow tutorials, use best practices, and start implementing your integration(s).
Informatica also provides documentation to get started (e.g. getting started guide for Cloud Application Integration (CAI)).
How IICS is structured
Informatica Intelligent Cloud Services (IICS) uses the concept of an organization (an “org”) as the highest level container for objects, which include assets, projects, connections. Orgs also contain a unique set of users and user groups. When on-boarding to IICS, a decision will have to be made on whether to use the existing org for UW-Madison, or use a new parent org with sub-orgs.
The purpose of this document is to help prepare for this decision.
Organizational hierarchy
IICS has a hierarchy structure to ensure separation between teams and departments.
This is an accordion element with a series of buttons that open and close related content panels.
Parent Orgs
A parent org is the highest level concept in IICS. A parent org can contain 1-to-many sub-orgs and user groups.
Sub-Orgs
A sub-org is functionally equivalent to a parent org, except some aspects are inherited from the parent org. For example, a sub-org inherits licenses and connectors from the parent org. Parent org secure agent groups can also be shared to sub-orgs.
Integrations can be monitored from the parent org to all sub-orgs, allowing the ability to get operational information for all environments in a single view.
A sub-org can not contain a sub-org. A sub-org can be created from within a parent org, or an existing org can be linked to a parent org to convert it into a sub-org.
User Group
A user group allows further separation/isolation within an org. If fine-grained authorization is needed within an org, a user group can be applied to objects (e.g. assets, connections, secure agents) to limit access to a subset of org users.
If no user group permissions are applied to an object, everyone within the org can access it.
User groups cannot contain other user groups.
Options
Use the Shared Org
This is the default and most commonly used option. For example, DCS, Admissions, SMPH, and DoIT-AIS use the same org per each deployment environment: one org for test and one org for prod. We use user groups to separate access control between projects and assets. There is no extra cost to go this route, but there are some considerations
This is an accordion element with a series of buttons that open and close related content panels.
Shared org considerations
- User group permissions are not applied by default: Users must remember to apply user group permissions to their objects, otherwise the entire org has full read-write access to those objects.
- Connections and projects are visible in the list of all connections/projects, even if those objects have user group permissions on them. As a result, you will see other departments’ projects and connections when browsing in the user interface, or when selecting a connection from dropdown menus. To help organize your own objects, we recommend namespacing them. See the Best Practices for more information.
- There are two parent orgs: one for test and one for production. This may be a drawback for some applications that need more development environments (e.g. dev, QA, staging). Objects can be named or organized to indicate a specific environment (e.g. “dev-mapping”, “dev-project”), but having multiple development environments represented in a single org is not recommended.
Use a Sub-Org
A sub-org is functionally equivalent to a parent org, except some aspects are inherited from the parent org. For example, a sub-org inherits licenses and connectors from the parent org. Currently, The Office of Data Management and Analytics Services (ODMAS) is provisioned in this way.
- Parent org secure agent groups can also be shared to sub-orgs.
- A sub-org cannot contain a sub-org. A sub-org can be created from within a parent org, or an existing org can be linked to a parent org to convert it into a sub-org.
Unlike using the shared org, using a sub-org approach has extra financial costs. Depending on your needs, the Integration Platform Team might be able to help cover the extra cost. Please contact the DoIT Integration Platform Team if this is something you would like to explore.
This is an accordion element with a series of buttons that open and close related content panels.
Sub-org recommendations
- Sub-orgs can be used for isolating different environments such as test, qa or prod.
- If your integration requires more than few integration assets and connections, then a sub-org may be a better fit.
- If fine-grained authorization is needed within an sub-org, a user group can be applied to objects (e.g. assets, connections, secure agents) to limit access to a subset of sub-org users.
Sub-org costs
Sub-orgs have an additional cost that is not included in the centrally funded shared service offering.
Types of integrations
There are two different Informatica services that are used for integration projects:
- Cloud Data Integration or CDI
- Cloud Application Integration or CAI
Depending on the integration criteria, projects can be built using either, or a hybrid approach when it would be beneficial to an individual project.
This is an accordion element with a series of buttons that open and close related content panels.
Cloud Data Integration
Informatica’s data integration service that allows you to create, schedule, and monitor tasks. It provides a variety of connectors to various data sources and provides mechanisms to transform and map data from source to target.
Best used for projects that have the following characteristics:
- Large batch jobs, i.e. nightly uploads
- Flat data structure
- High latency environment
- Periodic or scheduled jobs
- Connectors exists for environment
- Data migration
- Data Integration Hub
Cloud Application Integration
An event-driven and service-oriented application integration service. It provides capabilities such as event processing, service orchestration, and process management.
Best used for projects that have the following characteristics:
- Small batch jobs, i.e. single record updates
- Nested data structures, i.e. JSON, XML
- Low latency environment
- Event based / Real time integrations
- Direct access to APIs
- Business Processes
- Composite Services, APIs
Venn diagram examples of two different types of integration services
Cloud Data Integration and Cloud Application Integration are Informatica services that are used for integration projects. Depending on the integration criteria, projects can be built using either CDI or CAI, or a hybrid approach when it would be beneficial to an individual project.
