Re: [Architecture] [BPS] Creating a new UI page with a retry mechanism for failed BPEL activities in BPS
HI Hasitha, You mean adding another filter to filter out the instances which can be retried with each instance raw having another link with retry option ? I think it would be easier from a user's point of view to have another page Retry Failed Instances with the filtering options that are available in the current instance view. That way, user can directly go to that page and filter instances to retry. It can like a task list to an maintenance user. Regards Nandika On Wed, Jan 14, 2015 at 5:06 PM, Hasitha Aravinda hasi...@wso2.com wrote: We have two options. 1. List instances which have failed activites in existing instance list. We can introduce new tab similar to status filter [1] for filtering. 2. Since this is an admistrative task, we can introduce new Instance Management page as well. I think, 1st one is more suitable,, because literally this page shows instances in state Active with Failed activities. [1] - http://3.bp.blogspot.com/-N0vFMkGKinQ/Ut6XlhWNBoI/A6g/8U6EddGubag/s1600/bps.png Thanks, Hasitha. On Wed, Jan 14, 2015 at 3:11 PM, Thilini Anoratna thili...@wso2.com wrote: Hi all, The idea is to provide the users to view all failed activities of a BPEL process in a new UI page [1]. This is a part of the issue: A mechanism to recover failed activities when ODE events are disabled [2]. In WSO2 BPS, retry mechanism for failed activities is provided via the BPEL instance view when the BPEL activityLifecycle events are enabled. But when the events are disabled, there is no way to retry failed activities using management console. As a solution for this issue, a retry mechanism for failed activities has been added per each process instance by Hasitha. The current requirement is to create a new UI page displaying all the failed activities with a retry mechanism. Since this will be added to the product management console as a new page, under which category should it be added in the menu panel? Any feedback/suggestions on this matter would be appreciated. [1] https://wso2.org/jira/browse/BPS-469 [2] https://wso2.org/jira/browse/BPS-472 Thanks and regards. Thilini -- Thilini Anoratna Software Engineering Intern WSO2 Inc.; http://wso2.com lean.enterprise.middleware Mobile : +94 (0) 778955654 Email: thili...@wso2.com -- Hasitha Aravinda, Software Engineer, WSO2 Inc. Email: hasi...@wso2.com Mobile: +94 71 8 210 200 -- Nandika Jayawardana Senior Technical Lead WSO2 Inc ; http://wso2.com lean.enterprise.middleware ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Default version number when switching the build to released versions of jars
Changing group names will be lot of work? Thanks, Samisa... Samisa Abeysinghe Vice President Delivery WSO2 Inc. http://wso2.com On Thu, Jan 15, 2015 at 6:31 PM, Srinath Perera srin...@wso2.com wrote: Some components in our build have 1.0 .. 2.0 etc as version, but there are lot with 4.3.0. Now when we make the version independent of the , what is the what is the first version to switch to? Options 1. 5.0.0 (cannot do 1.0 as that is a earlier version and maven will get confused) 2. Change group names and do 1.0.0 I am inclined for #2 WDYT? --Srinath -- Blog: http://srinathsview.blogspot.com twitter:@srinath_perera Site: http://people.apache.org/~hemapani/ Photos: http://www.flickr.com/photos/hemapani/ Phone: 0772360902 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Meeting Note : Implement a Pluggable Version Strategy feature in APIManager
Hi Dinesh,
On Tue, Jan 13, 2015 at 11:11 AM, Dinesh J Weerakkody dine...@wso2.com
wrote:
Hi All,
I have tested the above proposed method with a fresh APIM 1.8 pack. We can
successfully create and invoke APIs as follows.
[image: Inline image 1]
Here what we do is simply add the version number to context. Also I have
removed version from the resulting synapse api xml file (smiler to default
version) otherwise we have to send version number after the context (Ex:
http://localhost:8280/1.0.0/docman/*1.0.0*/add).
Now we can invoke this API as follows since context is matching to request
url and this is default version.
http://localhost:8280/1.0.0/docman/add
With the above solution system doesn't allow us to create a new version of
the API. Currently synapse doesn't allow to use deferent contexts with same
API name.
Ex:
Name : DOCMan
Context : */1.0.0/docman*
Version: 1.0.0
Name : DOCMan
Context :* /2.0.0/docman*
Version: 2.0.0
We used a template as a context to overcome this situation.
[image: Inline image 2]
With this solution context will be same among all versions. We resolve the
context template when API is initializing in synapse runtime. There is
another issue came up with this solution. Synapse doesn't allow to use
version attribute in API xml without a version-type (version strategy)
attribute. URL is the only value that we can use with the version-type
attribute and when we invoke api we must send version after the context if
we use URL as the version strategy. We can introduce a new version strategy
to overcome this situation. For the time been I have disabled the
validation.
After above mentioned changes we can successfully deploy multiple versions
of the same API. But when we try to invoke the APIs we faced another issue.
When the request comes to APIM side there is a problem in authentication
handler.
We use context to check whether access is granted to the given token or
not. In APIM side tables we have context template but in runtime we send
resolved context. So there will be no matching access grants and request
will be rejected.
We have two solutions to overcome this issue.
- Have a separate column in APIM database to store the resolved
context (Use in runtime)
- Add a new attribute to RXT to store context template (This is used
to display the context template in UI when editing the API)
I think that the second option is better than adding new columns to the
tables.
Please share your suggestions or thoughts on this.
When storing the context in APIM DB, I think you have to keep the resolved
context not the structure of the context. Having the resolved context in
AM_API table will allow validating the key with a single SQL. As you have
identified, it would be enough to keep the structure of the context only in
RXT. No additional columns are needed on AM_API table.
Thanks
*Dinesh J. Weerakkody*
Software Engineer
WSO2 Inc.
lean | enterprise | middleware
M : +94 727 361788 | E : dine...@wso2.com | W : www.wso2.com
On Tue, Dec 23, 2014 at 5:43 PM, Dinesh J Weerakkody dine...@wso2.com
wrote:
*Participants*
APIM Team : Sumedha, Nuwan, Sanjeewa, Jo, Roshan, Lakshman, Dinesh
ESB Team : Kasun
*Redmine*
https://redmine.wso2.com/issues/153
We have discussed the following options as solutions to implement a
pluggable version strategy for APIM manager product.
*Option 1 : include version to context path*
We allow users to define API context as a template in API create UI.
Context = /api/{uri.var.version}/anytext
Version = 1.0.0
Then we generate the context path based on a the template when creating
the synapse xml and use default version-type (empty).
*Current version*
api xmlns=http://ws.apache.org/ns/synapse;
name=admin-API
context=/api”
version=1.0.0
*version-type=url*
*Proposed version*
api xmlns=http://ws.apache.org/ns/synapse;
name=admin-API
*context=/api/1.0.0*
version=1.0.0
Please note that version appended to context while version tag keeping as
it is. If user does not include the {uri.var.version}, current process will
be used.
Ex:
context=/1.0.0/api
context=/gov/1.0.0/api
context=/gov/1.0.0/api2
*Option 2 : Match APIs based on configured context pattern*
api xmlns=http://ws.apache.org/ns/synapse;
name=admin-API
context-pattern=”{uri.var.context}/{uri.var.version}”
context=/api”
version=1.0.0
version-type=url
Ex:
{uri.var.version}/{uri.var.context}= http://localhost:8280/1.0.0/api
{uri.var.context}/{uri.var.version}= http://localhost:8280/api/1.0.0/
In synapse level we have to uniquely identify a API with the context and
version. With second option, it will be difficult and can be lead to
conflicts If user define an API with context=”1.0.0” version=”api” while
having an API with context=”api” version=”1.0.0”. So we have decided to
drop the second option and throughly test the first option.
Please share your suggestions or thoughts on this.
