• State Not Answered
  • Replies 18 replies
  • Subscribers 11 subscribers
  • Views 6314 views
  • Users 0 members are here
Related Discussions
Home » Discussions » Data and Records

Hi all, we are in middle of planning for complete moving data from apps to

natasav
Hi all,
we are in middle of planning for complete moving data from apps to tempo interface.
We had a several discussions of what is appian best practise for doing that.
Now wee have several question about records. On the system customer wants to keep all data permanently , so we suggest to do some king of archiving or saving necessary data in SQL database and displaying those data by using tempo report and tempo records in same manner as portal reports and process instance dashboard.
So my question is it possible to set security on record data per instance or entry level in same manner as process instance security? And if it's possible how can we do it?
And on the other hand how can we display a html data by using sail?
BR,Natasa

OriginalPostID-191793

OriginalPostID-191793

  Discussion posts and replies are publicly visible

  • 0
    @csteward Thanks a lot, will go through your explanation and will try to comeback with questions incase if I have any.

    Actually my major concern here is not about the flexibility but I am trying to see if you have achieved any performance gain. Because I have implemented either of the approaches, that is, usage of groups(as mentioned in Appian docs)and getting the IDs where the user has been part of, but I have implemented both the approaches with Entity backed records. I am looking forward to see if you have made any difference with the Service backed records. Anyhow I will reach out to you after going through your comments.
  • 0
    Sure thing. I know we did see performance gains (would have to re-test for an accurate measurement), but for us the reasoning was entirely scalability (performance is a nice bonus). Also to mention, the method of utilizing the 'IN' operator on a returned list of all processes a user has been a part of did not work for us either - reason being the 1 MB data limitation of query rules stops somewhere in the range of 22k IDs (would also have to verify the #). We need upwards of 50,000 for some users currently so this was another road block. Service backed records solved both this and the group method shortcomings.
  • 0
    To expand briefly on the scalability, I ran a quick test this morning utilizing the IN operator on an entity-backed record, retrieving 50,880 records in the 'Value' (the Query Rule WAS able to retrieve that many). However, the Record works for 6-7 seconds then fails with this error in the log:

    The incoming tabular data stream (TDS) remote procedure call (RPC) protocol stream is incorrect. Too many parameters were provided in this RPC request. The maximum is 2100.

    That is a MSSQL limitation, assuming for which the IN operator can only be used (with poor performance) for records < 2100 potential items. Another reason we have chosen service-backed records as our primary solution.
  • 0
    Hi ,
    I just create a CDT and connected it to coresponding data source. Than I define a record as Entry based record and it showed OK. But when I define a default filter lika Viewers (multiple , text) include fn!loggedinuser() it showed an error and said that I could not used multiple field for filtering .Any idea how to define this filter ?
    Viewes shold be the list of usernames how will be pass from a process instance and it should be a way for defining of security.

    BR,Natasa
  • 0
    Hi Natasa, this is a drawback of record security currently - you cannot define the filter on a multiple data type. This was one of the primary reasons we went to Service Backed Records based on a!queryEntity(), as security can be implemented any way you wish with this type of record configuration. For this type of dynamic security, I would suggest browsing the documentation for service backed records: forum.appian.com/.../Service-Backed_Record_Tutorial.html

    If implementing, please note the documentation error within the "Configure the Source Expression for Navigation" section: totalCount of a!dataSubset() should be defined as "count(local!data)" instead, as pagingInfo does not contain a totalCount parameter.
  • 0
    Ok I change the logic and define the Service Based Record and than define the query rule on it:
    a!queryLogicalExpression(
    operator:"OR",
    filters:{
    a!queryFilter(
    field: "Viewers",
    operator: "include",
    value: loggedInUser()
    )
    }
    )
    It is OK with you?
  • 0
    +1 for the approach specified by @csteward.

    @natasav I would like to suggest to go through the tutorial in the link as mentioned above and also through the discussion made in current thread. I believe, the tutorial documentation is really a good point to start with, as they have specified everything step by step.

    To the best of my knowledge, we could make comments quickly and aptly, if you are able to provide a snapshot of the data structure.
  • 0
    By data structure you mean the CDT definition right?

    So you can find it in attach. I will take a detail look to proposed document and if I have some question I will share.
    Thanks in advance and we will be in contact.

© 2024 Appian. All rights reserved.
We want to hear from you! Submit a review on Gartner or G2.