Question
CIBC
CA
Last activity: 24 Jun 2017 10:56 EDT
service at FW layer and at Impl Layer
Hi,
I have built a service (service package, service, service activity to create a new case) under FW layer. When I switch to the impl layer, I could not see them under service definition. should I have to create another set of service package, service under impl layer in order to use?
thanks,
-
Like (0)
-
Share this page Facebook Twitter LinkedIn Email Copying... Copied!
BUPA
AU
By Definition, you won't be able to see it. There is no need to create unless specifically required. Service rules kept in FW layer should be able to create cases in Impl layer. You have to send the class name as a parameter to the service activity which in turn will create the case (may be calling AddWork). Pls share your full requirement if this answer is not clear.
CIBC
CA
Thanks for you reply. It is helpful. Yes, there will be one service activity take the parameters. I still have to create two services, one for FW and the other for Impl since this is the place to pass the parameter (class name) in, right? For the service package, one can hold both services.
Thanks again.
BUPA
AU
Service should be created in FW layer and the service activity should take the class name (Impl layer name) as parameter. By PRPC design principle It is not required to maintain services in different layers and you FW application should run as an application irrespective of Impl layer and Impl application
Updated: 13 Jun 2017 15:36 EDT
Pegasystems Inc.
US
If a service needs immediate access to a ruleset that is unique to a particular application (I am ignoring whether or not that application is considered the framework for some other application) then the service's Service Package's access group must point to that application pure and simple.
A service could queue a request that contains sufficient information that an Advanced Agent with the appropriate Access Group would know it should process the request as opposed to an Advanced Agent that has a different Access Group.
Or you could have a single application that, based on one or more "clues" within the request, either employs circumstancing or uses DCR to create and/or query pattern-inheritance-based classes as needed. Specialized classes can be placed in additional rulesets -- every business logic work/data rule does not have to be placed in the same ruleset.
As a last resort you could attempt to create a single "mega" application that contains every ruleset that contains "implementation" classes that directly extend "framework" classes, replying on DCR to point to the correct "implementation" class to use. This may or may not prove difficult to maintain. Care must be taken to avoid using ruleset overrides.
CIBC
CA
Hi, Thank to all of you for the comments.
In my scenario, at FW layer there are two Case Types: ORG-FW-BPMFW-Work-Case-Profit and ORG-FW-BPMFW-Work-Case-NonProfit.
A SOAP service is provided to create the cases by receiving the xml payload.
I created service activity (CreateNewCase that is calling svcAddWorkObject) at ORG-FW-BPMFW-Work-Case to have two parameters to receive the class names. Inside activity, based on parsed information (e.g type) to decide which case type to be created before calling svcAddWorkObject.
Hi, Thank to all of you for the comments.
In my scenario, at FW layer there are two Case Types: ORG-FW-BPMFW-Work-Case-Profit and ORG-FW-BPMFW-Work-Case-NonProfit.
A SOAP service is provided to create the cases by receiving the xml payload.
I created service activity (CreateNewCase that is calling svcAddWorkObject) at ORG-FW-BPMFW-Work-Case to have two parameters to receive the class names. Inside activity, based on parsed information (e.g type) to decide which case type to be created before calling svcAddWorkObject.
Meanwhile, I also have IMPL Layer case type: ORG-DIV-BPM-Work-Case-Profit and ORG-DIV-BPM-Work-Case-NonProfit.
Since the Service rule is the only place to pass the parameters to the activity. I need to create a Service Rule under IMPL layer RuleSet (using same ORG-FW-BPMFW-Work-Case as primary page and same activity) and pass the IMPL class names as parameter in order to create IMPL case type.
I don’t think we can pass the parameter via the Service rule.
Please advise. Thanks lot.
Pegasystems Inc.
US
Instead of trying to pass parameters, a better solution may be to use DCR and rules resolution to determine the class names. A service package (with Access group / application / rulesets) must exist at each layer you wish to invoke the service. Rule resolution can use this to determine the most specific data transform to populate the DCR values. Assuming you are trying to invoke the service at the fw or impl layer, a data transform of the same name would exist in the respective ruleset for each layer, thus populating the DCR values appropriately.
CIBC
CA
Thank you for your reply. It clears my confusion. In my scenario, A service package and a service must exist at IMPL layer since we will use IMPL AccessGroup/Application/RuleSets).
Thanks,
TCS
US
Yes, DCR is the best solution. Thank you all for this wonderful discussion!