Organizations

 

 

An Organization represents the company or entity using TIBCO Cloud Integration. It provides a logical boundary or container for Child Organizations where your apps and any associated configuration information reside. In most cases a TIBCO Cloud Integration account only has one Top-Level or Parent Organization, although additional Organizations can be purchased if necessary. 

Child Organizations
 

Child Organizations provide all the flexibility you might need to set up your app lifecycle. In your TIBCO Cloud Integration subscription you are granted access to your Top-Level or Parent Organization. At that point, you can choose how to organize the next level of your Organization by generating several Child Organizations similar to the following image. 

User management is configured separately for each Child Organization. A user can have different levels of access in different Organizations.

User management has the following roles available:

• Read-only access: User can see everything but cannot make any changes to the system.
• User access: User can create or update their own apps in the Organization and view apps owned by other users.
• Administrator access: User can make changes to any app and change the ownership of an app from one user to another.

By default, when a Child Organization is created it includes all users in the Parent Organization and those users inherit the roles they had in that Parent Organization.  After the Child is created, you can add individual users to that Child Organization without giving them access to the Parent Organization.

Managing Apps: Copy and Replace Operations

Apps are created inside a specific Organization and those apps are visible to all users in the whole Organization from the moment they are created. The user who creates the app is the owner of that app until ownership is changed or the app is removed.  Note: TIBCO Cloud Integration - Connect apps do not have a specific owner.

Regardless of how you are configuring or distributing the app, best practice is to use a Version Control system to store each version that you build and test, especially if you are collaborating with other people.

Important Notes:

• You can copy an app from one Organization to another one whether it is in the same account or in a different account. When copying apps be aware that new endpoints are generated for the new apps. This is not an upgrade app.

Note: TIBCO Cloud Integration - Connect apps cannot be copied from one Organization to another from within TIBCO Cloud Integration. Use the TIBCO Cloud Integration - Connect API instead.  See Copy Or Clone A Solution To Another Organization in the TIBCO Connect Developer Portal for instructions. A Solution is the equivalent of an app.

• Endpoints are kept for an app when using the replace operation. Updates to endpoints are not required for client apps or even TIBCO Mashery.  Replace operations are done with zero downtime.

 
 
Best practice is to have three environments/Child Organizations to manage your apps.

• One DEVELOPMENT Child Organization for developers working on a new app or new versions of existing apps.
• One STAGING/QA Child Organization for initial integration testing and user acceptance tests.
• One PRODUCTION Child Organization with zero downtime for your production environment.

The development, testing, and release process is shown in the next image.


Each movement between Child Organizations uses a different process depending on whether this is a new app or a new version of an existing app.



If this is a new app, we only need to copy it from the original Child Organization to the target one, using the final name we would like for the app.

If this is a new version of an existing app it is a multi-step process:

1. Copy the app from the original Child Organization to the target one, using a temporary name.
2. Replace the real app that is handling traffic with the temporary one copied in the previous step.
3. Remove the temporary app.

Managing Apps Among Organizations

In addition to using different Child Organizations to define logical environments based on the need for each of those environments and the different features and capabilities they provide, it is important to know that you can distribute or organize apps based on other criteria.

If you have four or five apps, it is not a problem to have all of them in the same Child Organization because it is not complicated to manage them. However, imagine that the number of apps is higher and you are attempting to manage 100, 200, or even 1000.? Even with features like Paging, managing such a large number of apps is difficult.  A simpler management method is to provide more Child Organizations.

Think of a Child Organization the same way you think of namespaces in Kubernetes, projects in Openshift, Domains in BusinessWorks, or Environments in AMX. In this case, the concept provides you with a way to organize your apps.   How you do that is up to you just as it would be in the prior examples. Following are some of the usual approaches for grouping apps:

• Split apps based on the business capabilities they provide and create a Child Organization for each of those capabilities, such as invoices, customers, or billing.
• Split apps based on the teams who develop them, using one Child Organization for each team.
• Split apps based on the technology being used, such as one for Flogo apps and another for BusinessWorks Container Edition.

In the end, you will have something similar to the following image, where your original environment Organization is split based on the grouping criteria you defined.



For this example, we split our apps into Environment A and Environment B. This division could be based on any criteria of your choice.

In this situation it is essential to have a well-defined naming convention for the Organizations to be able to easily differentiate them and also to know to which “logical environment” they belong.

Be aware that when exposing your services to the internet, it is exactly like you are communicating with an external third party.


User Management


To define the user management restrictions for those patterns and Child Organizations discussed earlier, use the following approach:

• Parent Organization:  Designed to be managed by DevOps and to contain production apps.  You are welcome to use it for other purposes.  Users added to this Organization are automatically copied to any Child Organization when that Child Organization is created.   Typically,  users in a Parent Organization also need access to the Child Organization.  The user who creates the Child is the Account Owner for the Child and can manage subscriptions.
• Development Child Organization (s): Managed and lead by Development teams. It makes sense for the administrator of this Child Organization to be the Developer Manager / General Developer Lead. If there is more than one Development Child Organization due to the number of apps, define the Team Lead as the Admin for that Organization. All the other developers should have the “User role” to be able to work within those Organizations.
• Test Child Organization / Production Child Organization: Managed by operation teams. The Operation Manager should be the Team Administrator and Admin for both Test and Production Child Organization, and other operation members should have access with a “User role”. If the Operation Team is split by “Environment”, choose which members should have the User role for each of the Child Organizations.  Developer Members can have “Read-Only access” to view log files, app properties and app metrics for troubleshooting.
• A User or Admin in one Organization (parent or child) can copy an app to another Organization (parent or child) as long as they are a member of the target Organization, regardless of their role.  This supports the idea of promoting from one environment to another.  You may want to add the user who is responsible for promoting the app (QA, for example) as a Read-Only user into the Organization that should receive the app.  If Users have a Read-Only role, they cannot update the copied app in that Organization, preventing further changes.  

General Best Practices

• Have at least one Child Organization for each logical environment you would like to handle from your account.
• Use the TIBCO® Cloud Integration - Command Line Interface to automate as many tasks as possible and use service-based accounts to ease the workload.
• Define a naming convention for Child Organizations to quickly identify the purpose for each one.

 

This whitepaper defines how to match your app lifecycle with all the power and possibilities of TIBCO Cloud Integration and provides best practices for app management in TIBCO Cloud Integration.