none
CCF LOB Applications Dependency - Disadvantages ! RRS feed

  • Question

  • As you are all aware that CCF uses front-end integration and thus, any changes to the LOB applications may/will effect the CCF Automation. Those include but not limited to:

     

    Screen design changes
    Change of fields arrangements
    Change of tabs sequence
    Change of application flow
    Change of application policy
    Change of existing shortcuts
    Change of screens name
    Change of URLs & tab index (web applications only)

     

    We have created a process of communicating the internal IT systems changes to the CCF team in order to implement those changes before the LOB application RFS date. However, this is adding an additional overhead over the current LOB applications teams and their RFS sometimes get delayed due to the request by the CCF team.

     

    My question here, is there away to get rid off such dependency ? I know this potentially means getting rid of CCF. Well, does Microsoft have any other approach? Not nocessary smiliar to CCF nevertheless, something which achieve automation for customer service without the dependency.

     

    How do you guys can keep maintaining it? What is your approach?

     

     

     

     

     

    Tuesday, September 16, 2008 9:27 AM

All replies

  • No input, no thoughts at least?

    Tuesday, September 23, 2008 9:17 AM
  • Sorry, I missed the post..

    Overall you make valid points.  Depending on the type of application there are various ways to deal with this problem.   However, we are effectively at the mercy of the end user application.

    A CCF adapter that is build correctly can generally tolerate these changes w/out causing outright breaking of the desktop.. From a fragility point of view,  Hosted controls are the strongest, followed by Web apps, and last External apps.

    Based on your list,  hosted controls should not be affected,  web applications should only be affected by application flow( and then only the workflow bits ) and URL changes (though you should handel this with config).  Using the web application adapter it should tolerate the rest.  External applications are the most intolerant of change.

    Note: We have substantially improved all of the application mapping system’s tolerance of change with CCF 2009.  There is a much greater focused on HAT driven Automation, along with improved mapping.

    Our guidance to customers in this area really emphasizes testing before deployment to the field and any map or automation updates as necessary.

    While I’m not familiar with the specifics of your environment,  it sounds like your CCF deployment may be a bit too tightly constructed,  you may want to reach out to your Microsoft TAM to have our deployment reviewed.   

    What version of CCF is this?

     

    Matt B

     

    Wednesday, October 15, 2008 9:36 PM
    Moderator
  • I recently completed a project involving CCF that integrated 4 web applications, 1 windows application (in VB6), two mainframe systems and about 4 hosted controls.

    One of our key tools we used to ensure that changes to the external applications don't break the integrated CCF app is by test automation. Our automated tests run to nearly 200 tests, this allows app devs to make changes to their app and ensure they don't break any of the integration.

    For a few of the tabs where automation was not possible we relied on a process similar to what you outlined, but the other way around. The app-devs were given guidelines on what they could (or on one tab couldn't) change.


    Friday, October 17, 2008 2:33 PM
  •  MattB-MSFT wrote:

    Note: We have substantially improved all of the application mapping system’s tolerance of change with CCF 2009.  There is a much greater focused on HAT driven Automation, along with improved mapping.

    Our guidance to customers in this area really emphasizes testing before deployment to the field and any map or automation updates as necessary.

    While I’m not familiar with the specifics of your environment,  it sounds like your CCF deployment may be a bit too tightly constructed,  you may want to reach out to your Microsoft TAM to have our deployment reviewed.   

    What version of CCF is this?

     

    Matt B

     

     

    Is there a way you can give more details about the application mapping system’s tolerance of change with CCF 2009?

     

    We have a support agreement with Microsoft however, it is just limited to the product support and does not cover the customerised enviroment though.

     

    We use CCF 2005

    Saturday, October 18, 2008 5:52 PM
  •  merillf wrote:
    I recently completed a project involving CCF that integrated 4 web applications, 1 windows application (in VB6), two mainframe systems and about 4 hosted controls.

    One of our key tools we used to ensure that changes to the external applications don't break the integrated CCF app is by test automation. Our automated tests run to nearly 200 tests, this allows app devs to make changes to their app and ensure they don't break any of the integration.

    For a few of the tabs where automation was not possible we relied on a process similar to what you outlined, but the other way around. The app-devs were given guidelines on what they could (or on one tab couldn't) change.


     

    Dear Merlif,

     

    This is really interesting. Is there a way you provide me with more details regarding this test automation tool and how to integrate it with CCF.

     

    Can you also, give me some of the guidelines provided to application developer on what they can and cannt change,

    Saturday, October 18, 2008 6:00 PM
  •  

    Ahh.. well you’re a few versions out J

    CCF 2008 introduced a tool call HAT (Hosted automation toolkit) and a concept called Dynamic data adapters.  These are cross compatible with the core engine and existing adapters and use WF to do automation.  In CCF 2009, in addition to several other features and updates, we have provided a Visual Studio Project type and pluging to support HAT.

    You can find the white paper on CCF 2008 here along with some inital information on CCF 2009.

    The 2009 White paper is not quite ready yet as its just gone GA. You may want to reach out to your Microsoft contacts to get a briefing on what’s new in it.  it is a substantial step up in feature set over 2008.

     

    MattB.

    Saturday, October 18, 2008 7:07 PM
    Moderator
  • We use a home-grown framework that wraps the calls to the Win32Api's, CCF comes with a few of them so you could use that too. The basic composition of each test is to start the application and perform a typical LOB activity that the user would perform and the step would complete with either a pass or fail. We used the MSTest framework to run the tests.

    As for the guidelines for CCF devs we pushed to keep things simple by only using control names when driving automation. The app devs would then use the doc published by the CCF devs that outlined the controls and actions that were being automated and ensured they would not step on its toes when making changes.
    Sunday, October 19, 2008 10:30 PM
  • Dear Merill

     

    We are facing some problems to develop an automation project to the Customer Care Acelerator product, using the Application Inspector tool with VB6 applications.

     

    This application contains the information that we need to use in the automation process as VB6 label values. But neither the Application Inspector or the Spy++ tool can get these controls properties. We also created another vb6 application to confirm this scenario and the result is the same, we can't map label controls.

     

    Is there a way to map the labels of a VB6 application? I can't map systems mainframe too. Please, cold you help me?

     

    Thanks,

    Monday, August 2, 2010 8:01 PM