Process for Existing TIBCO Cloud™ Integration Users

The June release of TIBCO Cloud Integration introduces some new concepts and features that you might want to take advantage of in your app lifecycle processes.. At a high level, this release changes the underlying logical separations within the product from sandboxes to organizations. Apps are now copied and replaced instead of being promoted and upgraded. Additional roles have been added to provide more access control for users. For more suggestions please take a look at the App Lifecycle in TIBCO Cloud Integration article in the TIBCO Community.

 

This article provides some guidance on how you might approach adopting these features. We have tried to outline the process we think would best serve the majority of our customers.  

 

Moving From Sandboxes To Organizations

 

In TIBCO Cloud Integration sandboxes were often used to provide some level of separation between apps. With the June release of TIBCO Cloud integration we are removing this logical separation making all apps visible to all users in an Organization.  From this point forward, you can create Child Organizations that serve the purpose of any required logical separation in which you can add appropriate users and set their permissions. Each top-level or Parent Organization can have multiple children. Child Organizations can be used individually as Development, QA, and production environments. Within each Organization, User roles are assigned to users to control access and permissions.

 

In this scenario, assume we have the standard Dev, QA and production environments with six users to demonstrate how this would work.  

 

The team includes the following users:

 

• Eric - Admin/DevOps
• Jon - Admin/Manager
• Dave & Alicia - User/Dev
• Morgan & Paul - User/QA

 

As a team, they decide to create two Child Organizations, Dev and QA, below their top-level Parent Organization, resulting in the following set of Organizations:

• ACME Org
• ACME Org - Dev
• ACME Org - QA

 

ACME is the Parent Organization.  When the Child Organizations are created, any existing TIBCO Cloud Integration users are copied to the newly created children.  

 

1. Eric determines that everyone should not have the same access level. He updates other users and changes their role to Read-Only (Dave, Alicia, Morgan, and Paul) in ACME Org. He could also opt to remove them altogether from the ACME Org because they do not need to do any work in the Parent Organization.   

2. Eric would then go into the Children and assign Jon as the team administrator of those Organizations.
3. Jon could then make changes based on how the Organizations should work together.  

4. Eric would copy non-production apps (based on tags and other details) to the respective Child Organizations and remove from the Parent Organization, ACME Org.
5. Jon would assign ownership of the apps to the respective Dev or QA users.  
6. Note that a User in one Organization can copy an app to another even if that user has a Read-Only role in the target Organization.  This is to allow cross-org deployment.

FAQS

This section provides answers to frequently asked questions regarding the June Release of TIBCO Cloud Integration.  

 

How do I get Child Organizations?

We’re giving existing TIBCO Cloud Integration Organizations (regardless of subscription) the capability to create Child Organizations.  

 

How are duplicate apps handled after the migration?

Each app is tagged with additional identifying information displayed on the app list UI. Best practice is to rename duplicates before doing any further work to prevent problems with pushing updated apps or replacing apps in TIBCO Cloud Integration. However, different procedures apply depending on what is being done with a duplicate app.

Assume that user Andy has BusinessWorks Apps with the same name in two of his personal sandboxes today:

• MyAppBW from MySandbox1
• MyAppBW from MySandbox2

In this case, after migration, there will be two MyAppBW apps on the app list UI in Andy’s Parent Organization. Each  app will have corresponding legacy tags containing the original sandbox names. Both MyAppBW apps will be running.
 

Scenario 1:

On his local system, Andy makes a change to the BusinessWorks project MyAppBW from MySandbox1. He then pushes the updated app from his machine to TIBCO Cloud Integration using either the TIBCO Cloud - Command Line Interface or BusinessWorks Studio.

 

The push will fail and generate an error message indicating that multiple apps with the same name, MyAppBW, were detected. The system is unable to decide which of the two to overwrite. A possible solution is to rename the MyAppBW with tag MySandbox2 to remove the ambiguity and push again.

 

Scenario 2:

 

Andy corrected a defect on the BusinessWorks project MyAppBW from MySandbox1 and exported the EAR archive and manifest.json file. The exported files need to replace those running in production using the TIBCO Cloud - Command Line Interface. Using the replace command preserves the endpoints:

 

tibcli app replace MyAppBW ...

 

The replace command will fail and generate an error message indicating that multiple apps with the same name, MyAppBW, were detected. The system cannot determine which one to replace. A possible solution is to rename the app that you do not want to replace and issue the replace command again.

 

Scenario 3:

 

There are also use cases where different owners have apps with the same names that are migrated from multiple user sandboxes to the same Parent Organization.

 

• MyAppX from Andy’s default sandbox
• MyAppX from Todd’s default sandbox

 

On his local system Andy updates his MyAppX. If Andy then attempts to push or replace his own MyAppX from Andy in TIBCO Cloud Integration, the overwrite is successful. In this case, there is no danger of Todd’s MyAppX being overwritten because the apps have different owners and the system can distinguish between the two.  In this case, the operation is handled without needing to rename one of the apps.

 

What about the impact on TIBCO Cloud™ - Proxy Agent?

• The TIBCO Cloud - Proxy Agent config per app will be preserved after migration
• Tunnel keys are by subscription. There is no impact on a per app basis by owner in the current Organization but the Proxy Agent cannot be used across Organizations with different Subscription IDs
• When copying an app from one Organization to another, the tunnel key will be removed and must be reconfigured because the current subscription ID will no longer be valid

How are TIBCO Cloud - Command Line Interface and my CI/CD processes impacted?

If you have installed Version 2.5.0 of the TIBCO Cloud - Command Line Interface, you can continue to use that version for most operations. Note that any commands related to sandboxes and deprecated app commands will no longer work since those commands have been changed or removed. In addition, TIBCO Cloud Integration now has the concept of roles to control access.

 

In the June 2019, new commands are being added to the TIBCO Cloud - Command Line Interface to accommodate the app operations introduced in this release.  You will get an error when trying to use old commands with the new TIBCO Cloud CLI. Keep in mind that permissions based on a user’s role are also in effect.  Review the following summary of changes listed below.

 

Change Summary

• “app promote" command changed to "app copy"
• "app upgrade" command changed to "app replace"
• "app list" will provide additional details including owner
• "org ftl" command allows configuration of FTL
• "app update --deploymentStage" the values of deployment stage have been changed from "draft/published" to "draft/live"
• "app update --visibility" command is new
• sandbox  commands have been removed

 

Previously, the steps to create an app and use it in a production environment were similar to the following:

 

1. Create an operational sandbox and configure endpoint visibility.
2. Push an app to your personal sandbox.
3. Promote the app to an operational sandbox.

 

After the June release, the steps for the same process would be similar to the following:

 

1. Push app to an Organization where you are a member.
2. Set endpoint visibility on the app. Note endpoint visibility defaults to public.
3. When the app is  tested, Copy it to your Production Organization.
4. If this is an existing app that you are updating, use the Replace command in Production to update the old app with the new version which preserves the endpoints.

 

How is the Publish to Mashery being updated?

 

If you are a TIBCO Cloud Mashery subscriber, there is a direct link between the Area of Mashery with your existing organization.  If you wish to publish from a Child Organization, you can use the Advanced option under Publish to do that.

 

I’m using TIBCO Cloud™ Live Apps - how has that changed?

 

At this point, Live Apps is linked to the Parent Organization.  You will want to use the existing Parent Organization to manage Live Apps during the different phases of development.  Apps in Child Organizations will not be accessible to the Live Apps available in the Parent Organization.

 

Do I have to do anything?

 

No, actually you don’t.  All apps continue to run as they always have.  You can choose to stay with a single organization if that meets your needs.  All endpoints stay the same.

 

How is licencing handled?

 

The number of instances of apps running across your parent and all children counts towards your licence limit.  You are responsible for overages.

 

How are BusinessWorks Apps impacted?

 

The existing BusinessWorks Studio is aware of sandboxes, but those will not be shown after the migration.  

 

We released a new Studio in early June that is not Sandbox aware.  You will no longer see the app explorer; you will only see the flat list of applications.  BusinessWorks is already multi-subscription aware including Child Organizations.

 

Note: The new user roles are applicable across TIBCO Cloud Integration apps pushed from BusinessWorks.

 

How are VPNs impacted?

 

VPNs are private per user.  If you are trying to run an app, the VPN must exist for you.

 

How are Connections impacted?

 

The impact is the same as it is for VPN. Connections are private per user.  If you are trying to run an app, the Connection must exist for you.

 

After the migration, I see duplicate app names?

There are tags added to each app to let you know which Sandbox it came from during the migration.  We suggest that you rename first before doing a replace.

 

In the Replace Dialog screen, I see duplicate apps?

 

We put tags on the various apps to help you understand which sandbox the app came from during the migration. Best practice is to rename the app before doing a replace. Renaming helps determine which app is being replaced. If you are moving development apps into a Child Organization that does not already contain any apps by the same names, renaming may not be necessary.

 

The June release of TIBCO Cloud Integration includes some new features and concepts that may require changes to your data.