API Explorer 106 endpoints

Get ObpActivity List

GET /obp/dynamic-entity/banks/obp.testing.01/ObpActivity

OBPv4.0.0-dynamicEntity_getObpActivityList_obp.testing.01 Roles: CanGetDynamicEntityRecord_ObpActivity(per bank) _ObpActivity(obp.testing.01)Dynamic-EntityDynamic

Get ObpActivity List.

Description of this entity, can be markdown text.

Property List:

  • name: description of name field, can be markdown text.
  • username: description of name field, can be markdown text.
  • created_date: description of number field, can be markdown text.

MethodRouting settings example:

<details>

{
  "is_bank_id_exact_match":false,
  "method_name":"dynamicEntityProcess",
  "connector_name":"rest_vMar2019",
  "bank_id_pattern":".*",
  "parameters":[
    {
        "key":"entityName",
        "value":"ObpActivity"
    }
    {
        "key":"url",
        "value":"http://mydomain.com/xxx"
    }
  ]
}

</details>

User Authentication is Required. The User must be logged in. The Application must also be authenticated.

Filtering, sorting and pagination on the list endpoint:

(no fields on this entity are declared indexed, so only the legacy bare-parameter filter below is available.)

  • Filter: ?obp_filter[FIELD]=OP:VALUE. Operators: eq, ne, in, lt, gt, le, ge, between, like, is_null, not_set. in / between take comma-separated values; is_null / not_set take no value. Repeat the same key to AND several constraints on one field. e.g. ?obp_filter[status]=eq:active&obp_filter[amount]=between:10,100 or ?obp_filter[closed_date]=not_set
  • Legacy filter (still supported): bare field parameters, e.g. ?name=James%20Brown&number=123.456&number=11.11 filters by name == "James Brown" && (number == 123.456 || number == 11.11).
  • Sort: ?obp_sort_by=FIELD[,FIELD2]&obp_sort_direction=ASC|DESC.
  • Paginate: ?obp_limit=20&obp_offset=40.

Filtering, sorting, pagination and is_null / not_set work on every deployment (no special backend required).

One-hop joins (EXISTS / NOT EXISTS) — filter this entity by a condition on a related entity linked through a declared reference: field:

  • ?obp_exists[RelatedEntity] — keep rows that have at least one related RelatedEntity.
  • ?obp_exists[RelatedEntity]=filter[FIELD]=eq:VALUE — ...that have at least one matching the predicate.
  • ?obp_not_exists[RelatedEntity] — keep rows with NO related RelatedEntity at all.
  • ?obp_not_exists[RelatedEntity]=filter[FIELD]=eq:VALUE — ...with no related RelatedEntity matching the predicate (this includes rows that have no related RelatedEntity).
  • If two entities are linked by more than one reference, disambiguate the edge with via:, e.g. ?obp_exists[RelatedEntity]=via:buyer_ref;filter[status]=eq:signed.

The nested filter[...] reuses the operator grammar above. Mind the distinction: obp_not_exists[X]=filter[flag]=eq:true (no related X with flag=true — includes rows with no X) is not the same as obp_exists[X]=filter[flag]=ne:true (has a related X with flag≠true — excludes rows with no X).

Only a field typed reference:<Entity> and declared indexed: true forms a join edge; a plain string field holding ids is not joinable.

Joins require the SQL projection backend (dynamic_entity.indexing.backend=auto on Postgres or SQL Server) with the involved fields indexed and ready. On an in-memory deployment a join query returns 400 (OBP-09022); while an index is still building it returns 409. The plain filter / sort / paginate / is_null / not_set features above do not need the projection backend.

Example success response
{
  "bank_id": "obp.testing.01",
  "obp_activity_list": [
    {
      "obp_activity_id": "d8839721-ad8f-45dd-9f78-2080414b93f9",
      "name": "James Brown",
      "username": "James Brown",
      "created_date": "698761728"
    }
  ]
}
Possible errors (3)
  • OBP-20001: User not logged in. Authentication is required!
  • OBP-20006: User is missing one or more roles:
  • OBP-50000: Unknown Error.
Implemented by OBPv4.0.0 dynamicEntity_getObpActivityList_obp.testing.01 Originally /banks/obp.testing.01/ObpActivity