[Oslc-Automation] Implementation issues when Automation type is not known

[Jing Qian]

Hi,

In a previous discussion, Pramod has proposed to a oslc_auto:automationType
attribute, but there is some objection to it,


see the thread here -
http://open-services.net/pipermail/oslc-automation_open-services.net/2012-June/000182.html

   Automation plan: We don't have oslc_auto:automationType attribute.
   Without
   this we can't distinguish whether Automation is for build, test,
   deployment, cloud etc.. I think this needs to be typed.

   <dnb>I actually do not agree with an approach that types the automation,
   there are some
   automation plans that might perform one or more of those different types

   as a part of the workflow (think a continuous integration or continuous
   delivery product - i.e., DevOps)... How would you characterize those?
   Also, some automation providers will exist that can support more than
   one
   type of automation and do not need them to be separated. What do we gain

   by forcing this?
   </dnb>

   <pchandor>I think when a AutomationPlan represents a group of
   Automations
   (like TestSuite in RQM, workflow in DevOps), it might make sense to call

   them "complex" type. Consider a scenario like user is defining a
   workflow
   in RTC, that when a build automation is completed, wants to run a Test
   Automation. When user will query automation from the automation provider

   (RQM), It would definitely like automation plan of 'test' type be listed

   to choose from. Do we think this should be defined in service providers
   name space?. I think having a type in spec will provide client hint
   about
   what type of  Automation plan it is.</pchandor>

   <dnb>I really think this is unnecessary, it is by choosing the
   automation plans from the provider
   where this "hint" of what the automation plan might do. I think that the

   type would like end up being close to unique per automation provider
   which
   kind of defeats the purpose. What about automation providers that can do

   some generic automation work, would it then be up to the Automation
   Provider to change and require the end user to define the type of
   automation it is from a list of categories. I do not see what the gain
   for
   the consumer is here... If I ask RQM and it returns test, if I ask RTC
   and
   it returns build, and if I ask RAF and it returns deployment (always in
   each of these cases) what is the purpose?</dnb>


I'm bringing this discussion up again, because from end user story point of
view, we have an issue not knowing the type of automation.

Consider this user scenario:
	As a RTC user, I want to set the test(automation) result inside my
build result so that I can view the test result directly from RTC.

When user configures the cross server communication in RTC, the steps are
usually the following

Step1 -  Set up server friend relationship

Step2 - Set up the project areas associations

   If the friend server is an automation provider that provides several
   types of automation (build, test, provision, deployment...etc.), it
   could be confusing for the user which one is for which.

   Here is an example, RQM is an automation service provider for both test
   and provisioning, this could be in its rootservice.xml

    		<jd:oslcCatalogs>
   		 		 <oslc:ServiceProviderCatalog
   rdf:about="https://myserver1.ibm.com:9443/qm/auto/test/catalog">
   		 		 		 <oslc:domain
   rdf:resource="http://open-services.net/ns/auto#"/>
       		 		</oslc:ServiceProviderCatalog>
   		 		 <oslc:ServiceProviderCatalog
   rdf:about="https://myserver1.ibm.com:9443/qm/auto/provision/catalog">
   		 		 		 <oslc:domain
   rdf:resource="http://open-services.net/ns/auto#"/>
   		 		 </oslc:ServiceProviderCatalog>
     		</jd:oslcCatalogs>

   As you can see, <oslc:domain> for these 2 service providers are the
   same, however, they just have different rdf:about URL, one is for test
   automation, the other is for provision automation.

   But to the end user, when they have to choose the project area
   association, all they see are 2 "Uses - Automation" choices, they don't
   know which one is for which.




	The association would show 2
				"Uses - Automation" options, with no additional
information to show which one is for test, which one is for provisioning

Step3 - Using a picker to choose an Automation result
	When programming this picker, it will need to be in the context of
some integration points, but if we don't know what type is the automation
association, how can we make sure we display the right content?

   	e.g.  we need to bring up the UI picker to choose an automation
   (test) result, but it could show a list of the automation result for
   provisioning rather than for test.


Jing J. Qian

Development, Rational Quality Manager
Rational Software
IBM Software Group
4205 S. Miami Blvd.
Durham, NC 27703

Tel: 919-254-9455 T/L: 444-9455
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20120702/84066cbc/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20120702/84066cbc/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 14973140.jpg
Type: image/jpeg
Size: 38328 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20120702/84066cbc/attachment-0001.jpg>